How to properly revoke refresh token for a multi-tenant application.

Question

So we have a custom asp.net app that utilizes Azure AD implicit grant flow for our Authentication. From there we create a JWT for our customers with proper claims (currently at 1 week expiry). Now, we wanna make sure that our JWT have shorter life span e.g. 15mins and is able to refresh it from time to time to ensure that the updated claims and permissions are always applied for our users.

We then decided to use the AAD authorization code flow for it.
-After Owin gets the authentication callback, we call the AAD token endpoint e.g. https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token to get a valid refresh token and store it in http-only secure cookie.
-Once the JWT expires, we check if the customer has a refresh token, and validate it against the same AAD token endpoint.
-Everything is working well, except for one thing that we wanna do now.

We wanna ensure that refresh_token we are giving for our customer can be invalidated if need to. Problem is all the options I tried below doesn't seem to be able to do it, my hunch is because to the fact that this is a multi-tenant application, and somehow the refresh token mechanism of AAD is tied up to the actual tenant of the user and not ours?

Things I tried

1. The invalidateAllRefreshToken endpoint of GraphApi, sure I verified it can invalidate the refreshtoken, but only if I logged in using the admin of the Tenant of the user, not when using as the admin of Tenant where this application is created to. https://learn.microsoft.com/en-us/graph/api/user-invalidateallrefreshtokens?view=graph-rest-beta&tabs=http
2. https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes Obviously this power shell approach is not supported anymore.
3. Lastly I am left with this https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime I don't know If need to do anything else but the sign in frequency doesn't seem to do anything at all with refresh_token invalidation. After 1hr, I can still use the same refresh_token over and over in token endpoint.

Are there anything else we can do to make sure refresh_token received from token endpoint can be invalidated by us? If this isn't doable, are there any alternative to accomplish the refresh mechanism that we want.

If we can't find any way to invalidate the refresh_token, we're just planning to totally ditch the authorization code flow of AAD and just generate a refresh_token ourself, but I wanna make sure that this is indeed not possible before proceeding.

Answer 1

Hello @jonathan , thank you for reaching out. I went through the details you shared and would like to share my understanding of the ask. So let's say we have a multi-tenant app originally developed and registered in Tenant A, where user A is the admin. This multi-tenant app gets added to another Tenant B, where user B is the admin. Now as I understood, you want userA should be able to invalidate the refresh tokens for Tenant B from Tenant A. If that's the ask, I don think you can do that as the Access_token and refresh_token pair is issued by the AAD Tenant that authenticates the user while the app is being accessed. Hence in this case, when a user of Tenant B would access the app, Tenant B's AAD would issue a token pair, and hence even if we configure CA policy that has to be configured in TenantB.

Do let me know if the above response helped you and my understanding of your ask are correct. If not, please do correct me at points where my understanding is incorrect, so that I can rectify my response and help you further with the ask.

Answer 2

hi @soumi-MSFT , your understanding of the question is indeed correct, it's clear now that my assumption is incorrect, that even though I am getting the token from /{tenantA}/endpoint, it turns out it is still the TenantB that is issuing the token under the hood. I thought that since there's a logical representation of the user from Tenant B to A which is the service principal, I thought that it would work, same thing that goes if Tenant B does not implement MFA, but we in Tenant A have policy for MFA the user would still be able to use MFA.

Now knowing that auth code flow will not be able to work for our requirement, do you see any other option we can use in AAD of Tenant A to shorten the life span of our JWT and have refresh mechanism?