I’m attempting to apply the revoke endpoint in our client-server application. The Okta document says I need to do client auth to call revoke endpoint for my OAuth2 access token and refresh token, but I have one problem. Because we wanted to keep our client apps to handle refresh token without being sent to server and our server keeps the client secret(but not client), the client app(front) cannot construct the clientID:clientSecret authorization header for the revoke request because the client secret is on server(backend).
Can I choose other authorization scheme than basic - base64 with clientID/secret?
Hi @tcho which token are you hoping the backend app will be able to revoke? It obviously won’t be able to revoke any token which the front end hasn’t passed it.
If the goal is to revoke the refresh, all access and all okta sessions, perhaps look at Users | Okta Developer. You can provide your backend with an administrative account which can do this. All it would need to know is the user you’d like to nuke all sessions for.
Thanks for the prompt reply. We wanted to revoke all of the access and refresh tokens returned from our client app. Ending session would be a solution but it could incur some weird experience for some user. For example, a user opens Okta website first and browsing user list, also opens a new tab for our app and login (SSO). When the user sign out from our app and return to the first tab for Okta, then they will see they logged out of Okta unexpectedly…
Any other suggestion? Can I use 'Authorization: Bearer ’ with access token for the /revoke endpoint?
Hmmm What’s the end goal you’re trying to achieve?
If you only revoke the access token that means the Okta session and refresh are still active and you can immediately get a new one, possibly negating the benefit of logging out.
The refresh token lifetime will also have a different duration to the Okta session (usually) so they’ll expire at different times.
One idea (would need a tech spike) is:
Front end passes the back end the tokens to be revoked (you’d make a new authenticated back-end API to receive them to avoid an application level DDOS)