0

We have a mail integration for MS mailboxes and we use MS Graph API for our integration. We have created an OAuth app and the right Mail scopes have been added to the app, while generating the access token we use the v2 OAuth endpoint mentioned in MS doc with .default scope.

The integration works fine for most cases but sometimes when a new user grants permission to the app, and we immediately generate access token using the refreshToken the scope contains only 1-2 scopes and the remaining scopes are missing from the token.

This is temporary and on further retry all the scopes are returned in the accessToken and we are able to access the mailbox. Is this due to some replication delay in MS end?

Here is the response for once such error :

AADSTS65001: The user or administrator has not consented to use the application with ID {'appID'} named {'appName'}. Send an interactive authorization request for this user and resource.
Trace ID: fc857dc7-0964-417e-9c3d-e23a3c0f9d00
Correlation ID: c9da409c-f988-4045-95b9-0a71113fdcdd
Timestamp: 2023-02-01 13:03:03Z

Scopes Granted to the application :

openid
profile
email
EWS.AccessAsUser.All
SMTP.Send
User.Read
Mail.ReadWrite
Mail.ReadWrite.Shared
Mail.Send
Mail.Send.Shared

Scopes Missing in Access token :

Mail.Send

PS : We use delegated access for the mailbox and token has offline access, also the userConsent flow is fine .

testUser FW1
  • 1
  • It does sound like an asynchronous process taking a moment on MS end. How much is the delay? How much time does it take for the retry to succeed? – juunas Feb 02 '23 at 11:59
  • @juunas yes seems to be the case, we have had scenarios where a req made within few seconds of user consent returns proper scopes and a subsequent call to for access toke after around 1-2 sec delay return only partial scopes. It seems to be dependent on the replication behaviour and the server that processes the access token request . In our testing, After around a min mark most of the access token request returned proper scopes. But I'm not sure if this will be the case for all requests , it might depend on region and other factors. – testUser FW1 Feb 02 '23 at 12:59

1 Answers1

0

I tried to reproduce the same in my environment and got the results successfully as below: 

I created an Azure AD Application and added API permissions: enter image description here I generated auth-code by using below endpoint:

https://login.microsoftonline.com/TenantID/oauth2/v2.0/authorize?
&client_id=ClientID
&response_type=code
&redirect_uri=RedirectUri
&response_mode=query
&scope=https://graph.microsoft.com/.default
&state=12345

enter image description here enter image description here 

I generated the access token using below parameters:

https://login.microsoftonline.com/TenantID/oauth2/v2.0/token
grant_type:authorization_code
client_id:ClientID
scope:https://graph.microsoft.com/.default
code:code
redirect_uri:https://jwt.ms
client_secret:ClientSecret

enter image description here 

I agree with @junnas, the issue occurred due to the replication delay of 1 or 2 sec in reflecting the scopes. When I decoded the access token, all the scopes are included like below:

 enter image description here

Imran
  • 3,875
  • 2
  • 3
  • 12
  • this flow is working fine for us, but the issue seems to be when there is a change in scope. if the user already has some of the scopes lets say EWS and IMAP scope, now if I add graphScope in the redirectURI and try to generate accessToken I'll get both old scopes and new scope even though we did not request for EWS and IMAP scopes in new token. And when trying to generate new accessToken immediately using the new refresh token we are getting only the old scopes and not the new graph ones. – testUser FW1 Feb 23 '23 at 09:45