Idea Details

OTK: Allow JWT access token to be revoked

Last activity 09-09-2019 03:33 AM
Joe Dascole's profile image
03-05-2019 09:22 AM

Request to add support for OTK to allow revocation of a JWT access token.

 

Currently in OTK 4.3, the revoke endpoint, /auth/oauth/v2/token/revoke, does not support revocation of a JWT access token. I understand the design is to prevent incorrectly granted access when validation is done locally but if logic can be added to address this it would be ideal.


Comments

09-06-2019 03:26 AM

09-04-2019 01:12 AM


The current behavior is a bit inconsistent : 

The revoke code just passes the access_token through and does a delete from the database : 
     delete from oauth_token where token='%1' 
so for uuid it finds an entry, for the jwt it does not. 

Unfortunately both (call with uuid and with jwt ) access_token return a success : 

{
    "result": "revoked"
}
But if afterward you call 
    /userinfo   
Then if revoke was done with uuid it returns a failure. 
Or if revoke was done with jwt then you get the returned userinfo contents -

ie with jwt token it is not really revoked. 
------

Explanation & Fix.

The database delete returns success if it does not find the entry - that make some sense since maybe the token is expired and already deleted from the database.

But has the side effect that any invalid token value will return a succesfull : "revoked" status even if it is an invalid token. 

The jwt access_token does contain the uuid inside it as an attribute. So the fix would be for revoke call to recognise this is a jwt token decode it and use the included uuid. 


Justification for current behavior

I think it really just needs a bit of retrofitting as per the last paragraph - but the justification give why the current behaviour is valid (and so an enhancement request is needed). 

The access_token as a jwt contains it's own exp expiry time after which it should not be used.   

The database table oauth_token entry also has a scheduled task that will delete entries as they expire. 

So when the expiry time is gone the entry will be deleted, and also the client can check the exp time in the access_token itself. 

And the revoke operation has no effect on the jwt access_token (and it's unfortunate it returns "revoked" status. 

I expect since the answer is fairly simple, and that it's not really a lot of work that it will be added in some future release. 

Cheers - Mark

03-05-2019 09:31 AM

We would like to see this working too as when the JWT is not validated locally , we would like to base the response on the status of the token at the authorization server.