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
------------------------------
Original Message:
Sent: 05-27-2020 10:05 AM
From: BARRY STERN
Subject: Revoke Access Token Only
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.
Original Message:
Sent: 05-27-2020 05:41 AM
From: Ewan Sadie
Subject: Revoke Access Token Only
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.
------------------------------
API Tech Lead
Sanlam
Original Message:
Sent: 05-26-2020 03:53 PM
From: BARRY STERN
Subject: Revoke Access Token Only
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
Original Message:
Sent: 05-26-2020 12:41 PM
From: Roan Linde
Subject: Revoke Access Token Only
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