Layer7 API Management

 View Only
  • 1.  Revoke Access Token Only

    Broadcom Employee
    Posted May 26, 2020 12:41 PM
    Hi there folks

    We have a client who is has a very specific use case to revoke a user's access token ONLY, and leave the refresh token in place. 
    The OAuth RFC 7009 does allow for either removing one or both depending on the auth server specifications. In our case, the backend SQL in the Gateway would remove the entry completely irrespective of whether you add `access_token` or `refresh_token` to the `token_type_hint`. 

    Confusingly, the OTK Swagger does say `access` OR `refresh` (found here)

    Is there any way to circumvent this? 

    Any comments would be greatly appreciated

    Regards, 

    Roan


  • 2.  RE: Revoke Access Token Only
    Best Answer

    Broadcom Employee
    Posted May 26, 2020 03:53 PM
    Hello,

    The OTK revocation policy revokes both tokens as recommended by the spec.

    The "token_type_hint" is used to tell the OTK policy what type of token  is being submitted it is not a indicator of what token to revoke. 


    Thanks
    Barry


  • 3.  RE: Revoke Access Token Only

    Broadcom Employee
    Posted May 26, 2020 04:10 PM
    Thanks Barry, 

    Appreciate your time & input

    Regards, 

    R


  • 4.  RE: Revoke Access Token Only

    Posted May 27, 2020 05:41 AM

    An extract from the RFC doc below

    If the particular token is a refresh token and the authorization server supports the
    revocation of access tokens, then the authorization server SHOULD
    also invalidate all access tokens based on the same authorization
    grant (see Implementation Note). If the token passed to the request
    is an access token, the server MAY revoke the respective refresh
    token as well.

    Based on this statement I see that the access token by default should be revoked on its own and revoking the refresh token is optional.
    If I compare the CA gateway behaviour with for example the IBM gateway (which by default only revokes the access token) then the gateway should make this optional (MAY revoke the refresh token) and the implementer should choose the behaviour.

    As a very crude workaround, this is what I did to facilitate the, in my mind, proper behaviour.
    There are many options I am not checking but the other policies are read-only.

    I hope these screenshots look better after upload.

    I modified /auth/oauth/v2/token/revoke as follow and added a SQL statement that expires the token. So it does not remove the access_token.
    I did not want to spend time to investigate the impact of clearing the field. By expiring the token I get the same end result.

    UPDATE oauth_token SET expiration=UNIX_TIMESTAMP(NOW()) WHERE token=${token}

    Feel free to supply comment on my "workaround" and where I can better it.


    ------------------------------
    API Tech Lead
    Sanlam
    ------------------------------



  • 5.  RE: Revoke Access Token Only

    Broadcom Employee
    Posted May 27, 2020 10:05 AM

    I understand your interpretation of proper behaviour, but the keyword here is " May" as per rfc2119 its optional and vendor in this case the Authorization Server to decide. 
    An extract from the RFC 2119

    MAY - This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.

    With that said the OTK is a frame work and designed to allow specifically the endpoints to be modified to support your requirements. so if you have a requirement to modify the out of box behavior to only remove the access_token and persist the refresh token you can.


  • 6.  RE: Revoke Access Token Only

    Posted May 27, 2020 11:36 AM

    Do you have any information on how to modify this framework if it was designed to be modified? I could not find any information in this regard. From my tests, most of the policies under the OTK are read-only.

    The revoke section does not have something similar to the =CUSTOM section under /token which does allow the modification and we have used this for multiple cases.

    The /revoke section seems quite rigid in this regard.

    And also the specific consumer is not interested in using the MAG SDK, which has different /revoke endpoints but requires the mutual SSL auth. They just want the behaviour to be the same as the other technology they already make use of.



    ------------------------------
    API Tech Lead
    Sanlam
    ------------------------------