OIDC authentication doesn't support custom URL schemes for native apps when using prompt=none

Xavi Moll 21 Reputation points
2021-02-11T15:04:17.74+00:00

I've implemented authentication using OpenID Connect on an iOS app. Everything works fine except for the token refresh when it expires. The option of prompt=none seems to be invalid while using custom URL schemes (i.e myapp://) for "security reasons": https://learn.microsoft.com/en-us/azure/active-directory/develop/reference-aadsts-error-codes Error code: AADSTS50199

The reason stated is that "a system webview has been used to request a token for a native application - the user must be prompted to ask if this was actually the app they meant to sign into." This is somehow true, but it also happens when using ASWebAuthenticationSession (which is my case), which the app doesn't have access to any of its contents and the user is prompted before opening by the system (can't be disabled) and it's the recommended way by Apple to perform OIDC auth.

This makes the UX of refreshing a token a nightmare, because the user is forced to interact with the website instead of silently refreshing it.

PS: There's some sort of workaround. Since http/https redirects are accepted, the app can implement Universal Links and detect the redirect from the secure browser back to the app, manually cancelling the native auth and injecting the code received on the AppDelegate to the Auth flow. This means that the prompt=none works without any user interaction, which makes the reason for disabling custom URL schemes pointless.

Microsoft Security | Microsoft Entra | Microsoft Entra ID
{count} votes

Accepted answer
  1. JamesTran-MSFT 36,906 Reputation points Microsoft Employee Moderator
    2021-02-23T19:33:53.507+00:00

    @Xavi Moll
    Thank you for your time and patience! We were able to get another update on this from our engineering team and I'll post it below.

    Update:
    This is confirm my sign in (CMSI). If Native apps were allowed to silently pop a browser, get new tokens, and close again without the user seeing more than a flash, there's no saying what app is actually being signed into.

    Mobile platforms don't secure custom URIs - For example, the Flashlight app can very easily sit on MyBank:// and request tokens as if it were your bank, taking advantage of the fact your already auth'd in the browser and consented to your bank app (which has registered MyBank:// as a redirect URI). So we cannot ever give a token back to a native app from the system browser without some user interaction where they confirm that the auth window launched by Flashlight app really matches their expectations.

    As of right now our engineering team will be looking into potentially implementing this, however, there is no ETA at this time.

    If you have any other questions, please let me know.
    Thank you again for your time and patience throughout this whole issue.

    ----------

    Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.

    1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
  1. Alfredo Revilla (Personal Account) 391 Reputation points
    2021-02-11T19:47:20.477+00:00

    Howdy, you should be able to bypass the prompt using the following schema:

    msauth.[Your_Bundle_Id]://auth

    Apple documentation does not requires a specific callback schema.

    PS: BTW what authentication library are you using?

    1 person found this answer helpful.

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.