OAUTH Spec non-compliance with microsoft Entra

Question

Hello,

My question is basically well recapped in this post https://learn.microsoft.com/en-us/answers/questions/993951/revoke-oauth-refresh-token-api that was really not sufficiently answered.

While I understand that the OpenIDConnect specification built on top of OAUTH2 doesn't explicitly state that a token revocation url is required it confounds me why Microsoft would choose NOT to include one when one is specified by the specification.

It seems like a glaringly huge security hole that after reviewing and reading about I just cannot find a satisfactory answer to so I am asking it here.

I also understand the answer provided in the question I linked states that the graph api and powershell commands can revoke a users signin session but that revokes their signin for ALL application not a specific application or a specific token (refresh or access tokens).

I also found an article from Microsoft (src: https://learn.microsoft.com/en-us/entra/identity-platform/configurable-token-lifetimes#access-tokens) that states:

"Access tokens can't be revoked and are valid until their expiry. A malicious actor that has obtained an access token can use it for extent of its lifetime."

Why in a world where the specification you are working in provides a revocation mechanism would this be the right process.

It seems that Microsoft's answer to this gap in their OAUTH2 implementation is to just shorten the lifetime of the access token but that doesn't solve the issue if the refresh token which is typically long lived.

Thanks in advance for anyone that can provide any reasoning or logic behind this.

Answer 1

Hello @Robert Lincoln

Thank you for posting your query on Microsoft Q&A.

Microsoft encourages using sign-in session management (e.g., session revocation or password reset) as the primary way to manage access control.

Your concern about refresh tokens and their long-lived nature is valid, and if more fine-grained control is necessary, you'll need to work within the constraints of the available Microsoft API tools or implement custom solutions as needed. 

Note: You cannot revoke access tokens. Access tokens are short-lived and by default valid for 1 hour. However, when the refresh tokens are revoked, the application will not be able to redeem the refresh tokens (long-lived tokens) to acquire new access tokens.

You may also consider setting access token lifetime to a lower value than 1 hour (minimum supported value is 10 minutes and the maximum is 1 day).

Refer to: https://learn.microsoft.com/en-us/azure/active-directory/develop/configure-token-lifetimes.

Read more: Access token lifetime

In general, if a user authenticates with Azure AD and checks the "Keep me signed in" box, a single sign-on session is established with the user’s browser and Azure AD. The Single Sign-On Session Token, in the form of a cookie, represents this session. It is important to note that the SSO session token is not bound to a specific resource/client application. SSO session tokens can be revoked, and their validity is checked every time they are used. 

Also, there are some features like token protection from the conditional access policy. Please refer the below document for more details:  https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection

You can use the below graph call to revoke the Refresh token: 

To revoke the refresh token of the signed-in user: 

POST https://graph.microsoft.com/v1.0/me/revokeSignInSessions 

To revoke the refresh token of another user: 

POST https://graph.microsoft.com/v1.0/users/object_id_or_upn_of_user/revokeSignInSessions 

Alternatively, you can use below PowerShell cmdlets as well: 

Revoke-AzureADSignedInUserAllRefreshToken 

Revoke-AzureADUserAllRefreshToken 

Hope this helps. Do let us know if you any further queries.

Best regards,

Sakshi Devkante