MortensterlundJrgensen-2743 avatar image
0 Votes"
MortensterlundJrgensen-2743 asked ·

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?

· 7
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thanks @MortensterlundJrgensen-2743 . Yes and this is expected and refresh tokens are revoked and its explained in the document -

0 Votes 0 ·

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)?

0 Votes 0 ·
JitendraRai-2073 avatar image JitendraRai-2073 MortensterlundJrgensen-2743 ·

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


0 Votes 0 ·
Show more comments

1 Answer

JasSuri-5387 avatar image
1 Vote"
JasSuri-5387 answered ·

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.

· 2 ·
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

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.

0 Votes 0 ·
JasSuri-5387 avatar image JasSuri-5387 MortensterlundJrgensen-2743 ·

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.

0 Votes 0 ·