app hitting v2 authentication endpoint instead of v1

Question

app hitting v2 authentication endpoint instead of v1

tavikukko opened this issue 5 years ago · 24 comments

We have suddenly faced issue that our app is authenticating against V2 endpoint. We are using V1 endpoint 'https://login.microsoftonline.com/common' and resourceUri scopes like https://graph.microsoft.com , https://tenant.sharepoint.com.
This is making our app not to work. We are using azure-activedirectory-library-for-objc version 4.0.4.
We are using MS Authenticator as a broker. Atm we are not sure if its MS Authenticator making this or azure-activedirectory-library-for-objc library.

/organizations/oauth2/v2.0/authorize?x-app-name=XXXX&x-client-brkrver=3.1.0&x-client-Ver=0.6.0&brkr=1&client-request-id=XXXXX&x-client-src-SKU=iOS&response_type=code&code_challenge_method=S256&x-client-CPU=64&x-app-ver=XXX&prompt=login&redirect_uri=x-msauth-XXXXXX&haschrome=1&state=XXXX&return-client-request-id=true&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default%20openid%20profile%20offline_access&x-client-SKU=MSAL.iOS&client_id=XXX&x-client-OS=13.3&client_info=1&x-client-DM=iPhone&code_challenge=XXXX

EDIT: removed MS Authenticator and the app was able to login.

GET /common/oauth2/authorize?x-client-Ver=4.0.4&state=xxxx&resource=https%3A%2F%2Fgraph.microsoft.com&prompt=login&response_type=code&x-client-OS=13.3&x-client-SKU=iOS&x-client-CPU=64&client-request-id=xxxx&redirect_uri=x-msauth-xxxx&client_id=xxxx&x-client-DM=iPhone&return-cli

So this might be issue in MS Authenticator.

EDIT2: this is also happening with android, with ms authenticator its V2 and without its V1.

and its affected 2 of our apps currently with both platforms.

we have also implemented both Schemes in our apps

<key>LSApplicationQueriesSchemes</key>
<array>
     <string>msauth</string>
     <string>msauthv3</string>
</array>

this issue seems related, but its closed.

#1462

Answer 1 · 2020-01-21T18:39:19.000Z

Hi @tavikukko : Thank you for reporting the issue.

Can you file a separate issue for Android so that it can be investigated by the Android team : https://github.com/AzureAD/azure-activedirectory-library-for-android

Also, Can you upload Authenticator logs incident id after repro'ing the issue for both iOS and Android to investigate this. Instructions below(similar for Android) :

https://github.com/AzureAD/azure-activedirectory-library-for-objc/wiki/Instructions-on-Collecting-Microsoft-Authenticator-Logs

Answer 2 · 2020-01-21T19:24:48.000Z

@tavikukko, The fact that iOS Authenticator goes to the v2 endpoint is expected. For the issues you're facing, iOS broker requires at least "profile openid offline_access" scopes.

To confirm you have correct configuration, can you please double check you app registration in portal.azure.com? You should at least have "user.read" under Microsoft Graph:

Answer 3 · 2020-01-21T19:27:13.000Z

yep we got 2, one for graph and 1 for sharepoint. This has been working for 3 years already for our first app and 1 year with our second.

Answer 4 · 2020-01-21T19:28:39.000Z

Thanks @tavikukko, just to confirm my understanding, do you also have "user.read" under Microsoft Graph like shown on the screenshot?

Answer 5 · 2020-01-21T19:29:42.000Z

tavikukko commented 5 years ago

Answer 6 · 2020-01-21T19:32:42.000Z

The things is, we got these permissions added to our aad app (automatically, we didn't add anything), and after that no new users were ably to consent the app.

Answer 7 · 2020-01-21T19:33:51.000Z

Thanks, @tavikukko. When did you notice the issue? iOS Authenticator has been going to v2 endpoint since June 2019 release, so there might be another regression/change that happened in between.

Answer 8 · 2020-01-21T19:35:13.000Z

I think we got first problem December 2019

Answer 9 · 2020-01-21T19:36:38.000Z

we updated to ADAL 4.0.4 between November-December..

Answer 10 · 2020-01-21T19:42:55.000Z

Here is a Incident ID: B9VZ4GKC
This one is from earlier today.

Answer 11 · 2020-01-21T19:44:28.000Z

Thanks, I've followed up with the AAD service team. I'll update you here once I hear from them.

Answer 12 · 2020-01-27T13:57:22.000Z

Hi,
any insights on this yet?

Answer 13 · 2020-01-28T22:42:12.000Z

@tavikukko, I'm still waiting for investigation results from AAD service team. I'll update you here once I hear from them. Sorry for a delay!

Answer 14 · 2020-02-11T18:51:37.000Z

@tavikukko, AAD service team has identified a regression on their side and they're working on the fix. They don't have exact ETA for the fix yet, and I've followed up on possible workarounds in the meantime. I'll update you here regarding possible workarounds.

Answer 15 · 2020-02-11T20:33:16.000Z

Massive thank you @oldalton !

Answer 16 · 2020-02-11T23:22:51.000Z

@tavikukko. I think the only workaround right now would be to use our MSAL library, and dynamic scopes. You can learn more about dynamic scopes and AAD v2 consent model here: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent. Sorry for the inconvenience.

Answer 17 · 2020-04-13T17:55:21.000Z

@tavikukko Are you still experiencing this issue?

Answer 18 · 2020-04-14T08:21:36.000Z

Hi @rohitnarula7176 ,
So it looks like the consent using MS Authenticator now consents the right scopes, but, when doing the consent flow using MS Authenticator, it still returns wrong scopes "openid profile email", not the one requested "AllSites.Write User.Read". When you sign out and back in, you get the correct scopes (when the consent flow not happening anymore)...so almost there.

Answer 19 · 2020-04-14T18:00:59.000Z

Thanks. Would you be able to provide Authenticator logs (incident ID) for this issue? See instructions on collecting them here: https://github.com/AzureAD/azure-activedirectory-library-for-objc/wiki/Instructions-on-Collecting-Microsoft-Authenticator-Logs

Answer 20 · 2020-04-15T08:51:05.000Z

Incident ID: NUFVKTF

Answer 21 · 2020-05-05T23:03:21.000Z

@tavikukko Thank you for providing the incident id . We looked at the logs but we do not log the actual access token to find the scopes returned as part of it. Can you please send us the scopes returned in the access token. You can use jwt.io to see the actual contents.

Answer 22 · 2020-05-06T05:23:30.000Z

@rohitnarula7176 Thanks for getting back to this. I removed the instance from Enterprise Application from my AAD and logged in again with the app using MS Authenticator to reproduce the problem with the consent and scopes. But now it works just fine and correct scopes to right resources are returned after successful consent.

I was checking the traffic while consenting and there the result:

POST /organizations/oauth2/v2.0/token

{
    "token_type": "Bearer",
    "scope": "openid profile email https://graph.microsoft.com/AllSites.Write https://graph.microsoft.com/.default",
    "expires_in": 3599,
    "ext_expires_in": 3599,
    "access_token": "eyJ0eXAiOi...

and here is the scopes in the access_token

{
  "aud": "https://graph.microsoft.com",
...
  "scp": "AllSites.Write openid profile email",
....
}

So seems like its fixed by AAD Team?

Answer 23 · 2020-05-08T22:01:15.000Z

@tavikukko, thanks for the information. Seems that consent saved for your account got a little bit mixed up due to the previous AAD bug. I believe it should be all good now.

Answer 24 · 2020-05-08T22:01:46.000Z

Closing this issue but feel free to reopen if you have additional questions.