revokeSignInSessions not revoking session cookies

I haven't had any success revoking the B2C session cookies with /users/{id}/revokeSignInSessions endpoint. I can see that it actually updates the "refreshTokensValidFromDateTime" property, so probably not a permission issue. Rejecting refresh tokens from before that date in a custom policy during sign in has no effect. I guess the custom policy is not even being run because the session cookie is still valid. It also seems not to have an effect in the default signin user flow.

It is an issue in particular in combination with Keep Me Signed In and revoking access globally (not only in the current browser, so calling /logout endpoint not an option). Lowering access token or cookie lifetime, or changing SingleSignOn Scope attribute is not an option. Changing the user's password does not invalidate the cookie either. Only way to invalidate the cookies seems to be to set Scope=Policy and forcing that user to a different policy or disabling the user. Then leave it like that until cookie expires (after days specified in SingleSignOn KeepAliveInDays attribute).

Am I doing something wrong?

Jitendra Rai 231 Reputation points

2021-03-04T08:47:48.787+00:00

Thanks @Morten Østerlund Jørgensen . Yes and this is expected and refresh tokens are revoked and its explained in the document - https://learn.microsoft.com/en-us/graph/api/user-revokesigninsessions?view=graph-rest-1.0&tabs=http
Morten Østerlund Jørgensen 26 Reputation points

2021-03-05T07:28:17.82+00:00

But according to the documentation you are linking to, it is supposed to also invalidate the cookie: "(as well as session cookies in a user's browser)".
So if that is not the case, there is no way to revoke the session cookies (than e.g. disabling the user, as I wrote)?
Jitendra Rai 231 Reputation points

2021-03-09T09:35:14.26+00:00

Thanks and this is the currently supported scenario. However you can verify by simply disabling the user, as we need to read the refreshTokenLastValidFrom timestamp on the user object. You could put a defaultValue for <OutputClaim ClaimTypeReferenceId="refreshTokenIssuedOnDateTime" />, and also adjust that it doesnt throw an error on failed lookup by adding the metadata item RaiseErrorIfClaimsPrincipalDoesNotExist:false

(e.g. https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-technical-profile#metadata).
Morten Østerlund Jørgensen 26 Reputation points

2021-03-09T11:02:13.6+00:00

Not sure how you want me to disable the user. I was referring to disabling the user in our own app, so rejecting the token issued by B2C in our app. In Azure portal B2C tenant in the user's profile I only see the option "Block sign in (yes/no)". Setting "yes" does not affect a client that already has a cookie.
Setting default refreshTokenIssuedOnDateTime and RaiseErrorIfClaimsPrincipalDoesNotExist=false does not reject existing cookie either.
See attached XMLs. Don't want to upload my full XMLs here, so tried to remove the non-relevant parts.

75842-trustframeworkbase.xml 75770-trustframeworkextensions.xml
Jitendra Rai 231 Reputation points

2021-03-09T13:47:56.163+00:00

Please follow the document to disable the user - https://learn.microsoft.com/en-us/answers/questions/84723/not-able-to-disable-user-account-using-accountenab.html

Patch https://graph.microsoft.com/v1.0/users/testuser1@.domain.onmicrosoft.com
Request Body - {"accountEnabled":"false"}
Morten Østerlund Jørgensen 26 Reputation points

2021-03-09T14:24:27.403+00:00
But what exactly do you want to achieve by disabling the user? Is it for you to be able to debug it? We don't want to disable the user. We want all cookies to be invalidated, but the legitimate owner of the account to be able to log in right afterwards.

It's very confusing what you are writing:

"this is the currently supported scenario": What does "this" refer to?

How is disabling the user and refreshTokenLastValidFrom related? If the user is disabled, then refreshTokenLastValidFrom must be irrelevant

Why would I want to add a default value or set RaiseErrorIfClaimsPrincipalDoesNotExist=false? I already wrote that I can see via the API that refreshTokensValidFromDateTime claim is being set when calling /revokeSignInSessions
Jitendra Rai 231 Reputation points

2021-03-09T15:55:46.837+00:00

Thanks @Morten Østerlund Jørgensen and let me discuss internally with your scenario and will get back to you.

1 answer

Jas Suri 91 Reputation points Microsoft Employee

2021-03-11T11:44:19.483+00:00

The Graph API command to revoke the session in respect to Azure AD B2C does not invalidate the B2C users session cookie. It only sets the refreshTokenLastValidFrom timestamp to the current time.

When using a SPA app, .Net App with PKCE flow, the users access token expiration will determine when the refresh token is subsequently used. If this exchange fails due to the /revoke endpoint being called, the user is asked to login again.

When the user is asked to login again, the Azure AD B2C web session sso cookies may give SSO if present and valid, as you note. Otherwise the user is asked to reauthenticate. You can force the behavior slightly by passing 'prompt=login' as part of the loginRedirect() method to clear the cookies in this scenario (when refresh token call fails).

You can also reduce the web session SSO liftetime such that the cookie is valid for a shorter period of time, somewhat mitigating how long the user may still have access without reauthenticating after the /revoke endpoint is called.

Be aware, that the refresh token in the SPA PKCE flow is only valid for 24 hours, and reducing the web session SSO lifetime will also effect users who have not had the /revoke endpoint called against them. For example if the user visits another application, they may not get SSO due to the shorter cookie lifetime.
Please sign in to rate this answer.

1 person found this answer helpful.
Morten Østerlund Jørgensen 26 Reputation points

2021-03-15T08:21:01.493+00:00

If the revoke endpoint does not revoke session cookies, why does the documentation explicitly say the opposite then? "(as well as session cookies in a user's browser)".

Did you notice that I wrote that we are using Keep Me Signed In? So how does it make sense to lower the lifetime? I explicitly mentioned that we do not want to do that.

Again, I explicitly mentioned that we want to log out clients globally and that in combination with KMSI, so how does it make sense to apply the "prompt=login"? In most cases we do not want to force reauthentication. We only want to do that for compromised accounts on machines that the legitimate user does not have access to.

Even if adding "prompt=login" was a solution, then the malicious user will be able to simply remove that query string parameter to circumvent that.

Jas Suri 91 Reputation points Microsoft Employee

2021-03-15T08:49:36.397+00:00

The only options you have are the ones I have explained, these are all the options for all other readers of this post also. If none of these are viable for you, which they are not in this case, then you will need to raise a feedback request for a new feature. We will adjust the MS Graph docs to reflect correctly.
Sign in to comment