When calling the revoke session method on the users api in the Okta dotnet SDK, the user’s session is revoked, but they are still able to make valid http calls to the .net web api secured by okta if they are currently logged into the Angular frontend. We are setting the OAuthTokens flag to true on the method, to revoke their access/refresh tokens, but that doesn’t seem to prevent them from making valid api calls still.
What is the proper approach to dealing with this scenario? This guide seems to indicate we do not need to validate the tokens if we are using .net core, but looking around it also seems like we need to bake our own solution using the /instrospect endpoint. If anyone could provide a proper guide or some direction, I’d appreciate it!
The user session is strictly for SSO. As long as there is a session the user may not have to authenticate again. Re-authentication and the addition of other authenticators (MFA) is controlled by the Global Session Policy applied to the user and the Authentication Policy the application is linked to, working together.
The API is reached with an OAuth access token that is issued during the call to /authorize for authentication. Access tokens have a finite lifetime, may be revoked by the application they were issued to, and may be refreshed indefinitely by that application. Tokens are not connected to SSO, so as long as the token is valid the API will accept it.
Okta allows an access token to be revoked, as a side note the Auth0 engine does not. The security issue here is a compromised token, which we go way out of the way to make sure doesn’t happen. If you are using OAuth2 Authorization Code Flow or Auth Code + PKCE flow, the token is protected by the application, it is not stored somewhere malware can access it. This is the reason that Auth0 does not support revocation, with a minimal chance of compromise normally discarding the token from memory satisfies all security requirements because nobody else has it.
If there is a SPECIFIC REQUIREMENT (I get those sometimes) to revoke tokens when no longer needed, then the only way to know that a token is revoked is to call /introspect and check it. There is no magic way that the token the application has gets updated after being revoked.
Remember, the application has to make the call to revoke the token. Just calling logout endpoint is not sufficient, that only ends SSO.
Are you saying that the oauthTokens flag on the revoke user sessions endpoint does not apply to the oauth tokens issued when calling /authorize? Or are you saying it does, but the only way to know that they’ve been revoked is to call /introspect?
Our ideal scenario would be that if a user is suspended/deactivated while they are currently in the application we would also revoke their sessions/tokens so that they can no longer make API requests. This didn’t seem like an out-of-the-ordinary scenario, so we figured the .NET Okta SDK would have something built into it to validate the tokens. Seems like a flaw to not detect if an access token is still active
For the first part of your question: think about this: if an application revoked a token only Okta knows about it, the content of the token in application memory doesn’t change. So if the application turned around and used the token with the API after revocation, the only way the API would know it was revoked would be to call /introspect. Local validation would still say the token is valid, hasn’t expired, good signature, etc.
When a user is suspended or deactivated, that is not an SSO thing. All issued tokens are automatically revoked. But, you’ll only know that by checking the token at /introspect.
That scenario only occurs if you want to terminate a worker or customer with extreme prejudice (walk them out the door, but they are really remote). In the CIAM world that scenario works, because you control all the applications and you can check the tokens. But in the case of third-party applications you would have to script Workflows or something to visit each application and deactivate the user account. And maybe, just maybe, if you deactivate an account (like at Salesforce), the user will be immediately turned away.
We were just trying to cover the scenario where a user’s account gets compromised, and we need to revoke their access immediately (terminate customer with extreme prejudice) from the application. It makes sense that we’d have to call the /introspect from each respective application and I had not thought of the third-party integration scenario, so thank you for mentioning that.
I will bring this info back to the team and we’ll make a decision from there.
Your welcome, thinking of all the scenarios is what I do
Also then think about this: the user could be in multiple SPAs or native apps (less likely) with compromised credentials. That’s almost impossible to fix, because the apps themselves could be proxies so checking /introspect doesn’t work, it isn’t actually your code. So put that call to /introspect on the API side definitely.
For traditional web apps you can trigger an OIDC back-channel logout. Then any logged in app gets notified and can kill their own session. Search for Okta OIDC back-channel.
