AADSTS50011: the specified reply URL does not match what is configured - azure-active-directory

I have seen a number of threads on this topic already. Apologies for adding another one but I haven't been able to solve my issue. I've created an ASP.NET Core 2.1 MVC application and published to Azure. The error is:
AADSTS50011: The reply url specified in the request does not match the reply urls configured for the application: 'a7f1d462-fce3-402c-9975-ac6f00c93a50'.
My appsettings.json is:
"AzureAd": {
"ClientId": "a7f1d462-fce3-402c-9975-ac6f00c93a50",
"Domain": "sentech.us",
"Instance": "https://login.microsoftonline.com/",
"TenantId": "<removed>",
"CallbackPath": "/signin-oidc",
"ClientSecret": "<removed>",
"AppIDURL": "https://sentech.us/LoginTest",
"ConfigView": "MVC"
}
Reply URLs:
https://logintest20180704120701.azurewebsites.net/signout-oidc
https://localhost:44319/signin-oidc
https://logintest20180704120701.azurewebsites.net/signin-oidc
The local host sign-in works fine. The app is simply the code created by Visual Studio by default with no modifications yet.
Thanks in advance for any help!

You need to set the Reply URL as the main url of your app and it needs to match the settings in the appsettings.json (and web.config if you have one). You do not appear to have a Reply URL set in your JSON so you need to add that there and in your solution. If you publish the solution you need to ensure that you change the Reply URL that you have set in your code to the published URL. This also needs to be set in your App Registration.
Please refer to my blog post and accompanying video.
See also this sample repository and documentation that should help you achieve what you are aiming for.

Related

Redirect URL changes from https to http after users authenticated with azure active directory in azure aks

I've been struggling to find a solution for this issue. Basically I have web application that allows users to sign in with their azure active directory using OpenIdConnect. Everything works perfectly fine on my local. However, when deployed to azure aks, somehow the redirect url changes from https to http when user is authenticated. This causes an exception in azure ad:
AADSTS50011: The redirect URI 'http://example.abc.com/signin-oidc' specified in the request does not match the redirect URIs configured for the application 'c853f6fe-5f4a-436e-b329-ff6da9ab89ab'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.
I defined the redirect URI in the application as https://example.abc.com/signin-oidc and no wonder that it does not match. However, I'm struggling to find out why it's happening and how I can resolve it. I'm using .NET 6 and AKS client version 1.22.
Any help would be greatly appreciated. Thank you
AADSTS50011: The redirect URI 'http://example.abc.com/signin-oidc' specified in the request does not match the redirect URIs configured for the application 'c853f6fe-5f4a-436e-b329-ff6da9ab89ab'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.
The above error occurs usually when redirect Url in the authentication are not configured in Azure AD like.
Accessing Website from a different address than what you have defined for your application causes an error.
please check if you have made a mistake in the configuration itself.
From your case :
Please make sure you set ssl redirects url to True
Note:
By default controller redirects HTTP clients to 443 port -https ,if it has TLS is enabled
In ingress routing yaml file if it is set to false, try to set it or modify it to true
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/use-regex: "true"
Also as you said you are using .net make sure you have set headers to true.
Please check that header size in 32k in annotations.
nginx.ingress.kubernetes.io/proxy-buffer-size: "32k"
Reference:
Error AADSTS50011 - The reply URL specified in the request does not match the reply URLs configured for the application . - Active Directory | Microsoft Docs
I finally figured out the solution for myself. Thanks to the answer in other SOF
Since I'm using .NET 6, all I have to do is
Set the ASPNETCORE_FORWARDEDHEADERS_ENABLED = true AND
Add these two lines suggested from #Venkatesan to my ingress yml
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/use-regex: "true"
Everything works perfectly after that.
Thank you everyone.

GMAIL API ACCESS ISSUE [duplicate]

On the website https://code.google.com/apis/console I have registered my application, set up generated Client ID: and Client Secret to my app and tried to log in with Google.
Unfortunately, I got the error message:
Error: redirect_uri_mismatch
The redirect URI in the request: http://127.0.0.1:3000/auth/google_oauth2/callback did not match a registered redirect URI
scope=https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email
response_type=code
redirect_uri=http://127.0.0.1:3000/auth/google_oauth2/callback
access_type=offline
approval_prompt=force
client_id=generated_id
What does mean this message, and how can I fix it?
I use the gem omniauth-google-oauth2.
The redirect URI (where the response is returned to) has to be registered in the APIs console, and the error is indicating that you haven't done that, or haven't done it correctly.
Go to the console for your project and look under API Access. You should see your client ID & client secret there, along with a list of redirect URIs. If the URI you want isn't listed, click edit settings and add the URI to the list.
EDIT: (From a highly rated comment below) Note that updating the google api console and that change being present can take some time. Generally only a few minutes but sometimes it seems longer.
In my case it was www and non-www URL. Actual site had www URL and the Authorized Redirect URIs in Google Developer Console had non-www URL. Hence, there was mismatch in redirect URI. I solved it by updating Authorized Redirect URIs in Google Developer Console to www URL.
Other common URI mismatch are:
Using http:// in Authorized Redirect URIs and https:// as actual URL, or vice-versa
Using trailing slash (http://example.com/) in Authorized Redirect URIs and not using trailing slash (http://example.com) as actual URL, or vice-versa
Here are the step-by-step screenshots of Google Developer Console so that it would be helpful for those who are getting it difficult to locate the developer console page to update redirect URIs.
Go to https://console.developers.google.com
Select your Project
Click on the menu icon
Click on API Manager menu
Click on Credentials menu. And under OAuth 2.0 Client IDs, you will find your client name. In my case, it is Web Client 1. Click on it and a popup will appear where you can edit Authorized Javascript Origin and Authorized redirect URIs.
Note: The Authorized URI includes all localhost links by default, and any live version needs to include the full path, not just the domain, e.g. https://example.com/path/to/oauth/url
Here is a Google article on creating project and client ID.
If you're using Google+ javascript button, then you have to use postmessage instead of the actual URI. It took me almost the whole day to figure this out since Google's docs do not clearly state it for some reason.
In any flow where you retrieved an authorization code on the client side, such as the GoogleAuth.grantOfflineAccess() API, and now you want to pass the code to your server, redeem it, and store the access and refresh tokens, then you have to use the literal string postmessage instead of the redirect_uri.
For example, building on the snippet in the Ruby doc:
client_secrets = Google::APIClient::ClientSecrets.load('client_secrets.json')
auth_client = client_secrets.to_authorization
auth_client.update!(
:scope => 'profile https://www.googleapis.com/auth/drive.metadata.readonly',
:redirect_uri => 'postmessage' # <---- HERE
)
# Inject user's auth_code here:
auth_client.code = "4/lRCuOXzLMIzqrG4XU9RmWw8k1n3jvUgsI790Hk1s3FI"
tokens = auth_client.fetch_access_token!
# { "access_token"=>..., "expires_in"=>3587, "id_token"=>..., "refresh_token"=>..., "token_type"=>"Bearer"}
The only Google documentation to even mention postmessage is this old Google+ sign-in doc. Here's a screenshot and archive link since G+ is closing and this link will likely go away:
It is absolutely unforgivable that the doc page for Offline Access doesn't mention this. #FacePalm
For my web application i corrected my mistake by writing
instead of : http://localhost:11472/authorize/
type : http://localhost/authorize/
Make sure to check the protocol "http://" or "https://" as google checks protocol as well.
Better to add both URL in the list.
1.you would see an error like this
2.then you should click on request details
after this , you have to copy that url and add this on https://console.cloud.google.com/
go to https://console.cloud.google.com/
click on Menu -> API & Services -> Credentials
you would see a dashboard like this ,click on edit OAuth Client
now in Authorized Javascript Origins and Authorized redirect URLS
add the url that has shown error called redirect_uri_mismatch i.e here it is
http://algorithammer.herokuapp.com , so i have added that in both the places in
Authorized Javascript Origins and Authorized redirect URLS
click on save and wait for 5 min and then try to login again
This seems quite strange and annoying that no "one" solution is there.
for me http://localhost:8000 did not worked out but http://localhost:8000/ worked out.
This answer is same as this Mike's answer, and Jeff's answer, both sets redirect_uri to postmessage on client side. I want to add more about the server side, and also the special circumstance applying to this configuration.
Tech Stack
Backend
Python 3.6
Django 1.11
Django REST Framework 3.9: server as API, not rendering template, not doing much elsewhere.
Django REST Framework JWT 1.11
Django REST Social Auth < 2.1
Frontend
React: 16.8.3, create-react-app version 2.1.5
react-google-login: 5.0.2
The "Code" Flow (Specifically for Google OAuth2)
Summary: React --> request social auth "code" --> request jwt token to acquire "login" status in terms of your own backend server/database.
Frontend (React) uses a "Google sign in button" with responseType="code" to get an authorization code. (it's not token, not access token!)
The google sign in button is from react-google-login mentioned above.
Click on the button will bring up a popup window for user to select account. After user select one and the window closes, you'll get the code from the button's callback function.
Frontend send this to backend server's JWT endpoint.
POST request, with { "provider": "google-oauth2", "code": "your retrieved code here", "redirect_uri": "postmessage" }
For my Django server I use Django REST Framework JWT + Django REST Social Auth. Django receives the code from frontend, verify it with Google's service (done for you). Once verified, it'll send the JWT (the token) back to frontend. Frontend can now harvest the token and store it somewhere.
All of REST_SOCIAL_OAUTH_ABSOLUTE_REDIRECT_URI, REST_SOCIAL_DOMAIN_FROM_ORIGIN and REST_SOCIAL_OAUTH_REDIRECT_URI in Django's settings.py are unnecessary. (They are constants used by Django REST Social Auth) In short, you don't have to setup anything related to redirect url in Django. The "redirect_uri": "postmessage" in React frontend suffice. This makes sense because the social auth work you have to do on your side is all Ajax-style POST request in frontend, not submitting any form whatsoever, so actually no redirection occur by default. That's why the redirect url becomes useless if you're using the code + JWT flow, and the server-side redirect url setting is not taking any effect.
The Django REST Social Auth handles account creation. This means it'll check the google account email/last first name, and see if it match any account in database. If not, it'll create one for you, using the exact email & first last name. But, the username will be something like youremailprefix717e248c5b924d60 if your email is youremailprefix#example.com. It appends some random string to make a unique username. This is the default behavior, I believe you can customize it and feel free to dig into their documentation.
The frontend stores that token and when it has to perform CRUD to the backend server, especially create/delete/update, if you attach the token in your Authorization header and send request to backend, Django backend will now recognize that as a login, i.e. authenticated user. Of course, if your token expire, you have to refresh it by making another request.
Oh my goodness, I've spent more than 6 hours and finally got this right! I believe this is the 1st time I saw this postmessage thing. Anyone working on a Django + DRF + JWT + Social Auth + React combination will definitely crash into this. I can't believe none of the article out there mentions this except answers here. But I really hope this post can save you tons of time if you're using the Django + React stack.
In my case, my credential Application type is "Other". So I can't find Authorized redirect URIs in the credentials page. It seems appears in Application type:"Web application". But you can click the Download JSON button to get the client_secret.json file.
Open the json file, and you can find the parameter like this: "redirect_uris":["urn:ietf:wg:oauth:2.0:oob","http://localhost"]. I choose to use http://localhost and it works fine for me.
When you register your app at https://code.google.com/apis/console and
make a Client ID, you get a chance to specify one or more redirect
URIs. The value of the redirect_uri parameter on your auth URI has to
match one of them exactly.
Checklist:
http or https?
& or &?
trailing slash(/) or open ?
(CMD/CTRL)+F, search for the exact match in the credential page. If
not found then search for the missing one.
Wait until google refreshes it. May happen in each half an hour if you
are changing frequently or it may stay in the pool. For my case it was almost half an hour to take effect.
for me it was because in the 'Authorized redirect URIs' list I've incorrectly put https://developers.google.com/oauthplayground/ instead of https://developers.google.com/oauthplayground (without / at the end).
The redirect url is case sensitive.
In my case I added both:
http://localhost:5023/AuthCallback/IndexAsync
http://localhost:5023/authcallback/indexasync
If you use this tutorial: https://developers.google.com/identity/sign-in/web/server-side-flow then you should use "postmessage".
In GO this fixed the problem:
confg = &oauth2.Config{
RedirectURL: "postmessage",
ClientID: ...,
ClientSecret: ...,
Scopes: ...,
Endpoint: google.Endpoint,
}
beware of the extra / at the end of the url
http://localhost:8000 is different from http://localhost:8000/
It has been answered thoroughly but recently (like, a month ago) Google stopped accepting my URI and it would not worked. I know for a fact it did before because there is a user registered with it.
Anyways, the problem was the regular 400: redirect_uri_mismatch but the only difference was that it was changing from https:// to http://, and Google will not allow you to register http:// redirect URI as they are production publishing status (as opposed to localhost).
The problem was in my callback (I use Passport for auth) and I only did
callbackURL: "/register/google/redirect"
Read docs and they used a full URL, so I changed it to
callbackURL: "https://" + process.env.MY_URL+ "/register/google/redirect"
Added https localhost to my accepted URI so I could test locally, and it started working again.
TL;DR use the full URL so you know where you're redirecting
2015 July 15 - the signin that was working last week with this script on login
<script src="https://apis.google.com/js/platform.js" async defer></script>
stopped working and started causing Error 400 with Error: redirect_uri_mismatch
and in the DETAILS section: redirect_uri=storagerelay://...
i solved it by changing to:
<script src="https://apis.google.com/js/client:platform.js?onload=startApp"></script>
Rails users (from the omniauth-google-oauth2 docs):
Fixing Protocol Mismatch for redirect_uri in Rails
Just set the full_host in OmniAuth based on the Rails.env.
# config/initializers/omniauth.rb
OmniAuth.config.full_host = Rails.env.production? ? 'https://domain.com' : 'http://localhost:3000'
REMEMBER: Do not include the trailing "/"
None of the above solutions worked for me. below did
change authorised Redirect urls to - https://localhost:44377/signin-google
Hope this helps someone.
My problem was that I had http://localhost:3000/ in the address bar and had http://127.0.0.1:3000/ in the console.developers.google.com
Just make sure that you are entering URL and not just a domain.
So instead of:
domain.com
it should be
domain.com/somePathWhereYouHadleYourRedirect
Anyone struggling to find where to set redirect urls in the new console: APIs & Auth -> Credentials -> OAuth 2.0 client IDs -> Click the link to find all your redirect urls
My two cents:
If using the Google_Client library do not forget to update the JSON file on your server after updating the redirect URI's.
I also get This error Error-400: redirect_uri_mismatch
This is not a server or Client side error but you have to only change by checking that you haven't to added / (forward slash) at the end like this
redirecting URL list ❌:
https://developers.google.com/oauthplayground/
Do this only ✅:
https://developers.google.com/oauthplayground
Let me complete #Bazyl's answer: in the message I received, they mentioned the URI
"http://localhost:8080/"
(which of course, seems an internal google configuration). I changed the authorized URI for that one,
"http://localhost:8080/" , and the message didn't appear anymore... And the video got uploaded... The APIS documentation is VERY lame... Every time I have something working with google apis, I simply feel "lucky", but there's a lack of good documentation about it.... :( Yes, I got it working, but I don't yet understand neither why it failed, nor why it worked... There was only ONE place to confirm the URI in the web, and it got copied in the client_secrets.json... I don't get if there's a THIRD place where one should write the same URI... I find nor only the documentation but also the GUI design of Google's api quite lame...
I needed to create a new client ID under APIs & Services -> Credentials -> Create credentials -> OAuth -> Other
Then I downloaded and used the client_secret.json with my command line program that is uploading to my youtube account. I was trying to use a Web App OAuth client ID which was giving me the redirect URI error in browser.
I have frontend app and backend api.
From my backend server I was testing by hitting google api and was facing this error. During my whole time I was wondering of why should I need to give redirect_uri as this is just the backend, for frontend it makes sense.
What I was doing was giving different redirect_uri (though valid) from server (assuming this is just placeholder, it just has only to be registered to google) but my frontend url that created token code was different. So when I was passing this code in my server side testing(for which redirect-uri was different), I was facing this error.
So don't do this mistake. Make sure your frontend redirect_uri is same as your server's as google use it to validate the authenticity.
The main reason for this issue will only come from chrome and chrome handles WWW and non www differently depending on how you entered your URL in the browsers and it searches from google and directly shows the results, so the redirection URL sent is different in a different case
Add all the possible combinations you can find the exact url sent from fiddler , the 400 error pop up will not give you the exact http and www infromation
Try to do these checks:
Bundle ID in console and in your application. I prefer set Bundle ID of application like this "org.peredovik.${PRODUCT_NAME:rfc1034identifier}"
Check if you added URL types at tab Info just type your Bundle ID in Identifier and URL Schemes, role set to Editor
In console at cloud.google.com "APIs & auth" -> "Consent screen" fill form about your application. "Product name" is required field.
Enjoy :)

How to use ADFS Webfinger Endpoint?

I'm very new to ADFS and the Web Application Proxy. That said, I've recently setup an ADFS server and a WAP server and have all of the configuration setup to successfully handle SAML SSO to my custom application.
I am now attempting to use the Webfinger endpoint. By default, that endpoint is enabled (and proxy enabled). Unfortunately, I have not been able to get any meaningful response from this endpoint and am unsure even how to set it up. Searching for "ADFS Webfinger" documentation has been fruitless. Honestly, I can't find anything other than discussions of an Event Viewer error and other useless information.
I have attempted various combinations of URLs.
https://my-adfs-server/.well-known/webfinger?resource=https%3A%2F%2Fmy-adfs-server%2Fadfs%2F/ls&rel=http://schemas.microsoft.com/rel/trusted-realm
This gives me back a JSON:
{
"subject": "https://my-adfs-server",
"links": [
{
"rel": "http://schemas.microsoft.com/rel/trusted-realm",
"href": "https://my-adfs-server"
}
]
}
but it is the only URL I have found that returns anything.
https://my-adfs-server/.well-known/webfinger?resource=acct:<myemail>
This gives me a 404 with a valid email (acct).
What am I missing? Even if that last URL was working, how do I resolve it to specify information that should be returned in the JRD document for this particular account? Do I need IIS installed (I don't have it installed currently) and custom code?
Thanks for any help/insight.
Pink

Saml response sent to default reply URL under app registrations

I have a custom web app registered with azure. The reply URL is mentioned in the SSO settings and it was working fine. but last week we were not able to access the app we found that SAML response was being sent to loopback address URL (https://127.0.0.1:444/applications/default.aspx) which is default reply URL available under app registrations when we registered the app.Could not get any information from audit logs.
could you please let us know what could be the possible reason for SAML response being to Loopback address?
we haven't done any changes to reply URL. we checked with application team and updated the reply URL with new URL and it worked again.
Ok, not a satisfying answer since I can't say what broke, but one of my apps started doing this today and I was able to fix it. Basically it forgot/was ignoring your setting.
I had to go into the Enterprise Application, Single sign-on, then to the domains and URLs. Change the reply URL to a dummy address (I copied the good reply url to relay state, but as long as you don't lose it you can put it anywhere). I then tested and instead of going to https://127.0.0.1:444/applications/default.aspx, I went to the dummy reply address I put in.
Then I was able to go back, put the Reply URL back to the correct setting and we're back in business.
We had this same problem today. On 4 of our Azure SSO apps.
All of our apps have two Reply URLs. But only 4 of them were down.
Users were seeing the "can't reach this page" error in the browser, with the https://127.0.0.1:444 address.
We fixed by editing the Reply URLs on each app's App Registration.
We removed the https://127.0.0.1:444 entry.
Still not sure why only four of our SSO apps were affected. All others worked fine without being changed.

AADSTS50011: The reply url specified in the request does not match the reply urls configured for the application: '<AppId>'

I have a .NET Core 2 app template that is configured to use Azure AD out of the box.
The configuration is:
{
"AzureAd": {
"Instance": "https://login.microsoftonline.com/",
"Domain": "lautaroarinolive.onmicrosoft.com",
"TenantId": "67cb2dfd-ebd5-40d8-829b-378340981a17",
"ClientId": "50819a7a-e018-4c1d-bf0a-18c8fce5c600",
"CallbackPath": "/signin-oidc"
},
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Warning"
}
}
}
In my portal, I have an Azure app registration with the same id as ClientId. It has the reply URL [APP-URL]/signin-oidc.
The localhost app works only if I set the reply URL to [LocalhostURL]/signin-oidc, even though I've learned that the configuration should not affect log in on localhost.
The Azure app does not work in any case.
In both apps when it doesn't work I get this error:
AADSTS50011: The reply url specified in the request does not match the
reply urls configured for the application:
'50819a7a-e018-4c1d-bf0a-18c8fce5c600'
Is it correct that a localhost app should not need a configured reply URL?
Why do I get the "reply url not configured" error?
You can refer to this Sample to rebuild your .NET core App and publish to the Azure.
There are some NOTES you need to pay attention to :
you need to change the port from 5000 to the effective one. Currently, it should be 61659. So, when you do a test in your localhost, you can set the reply URL in the AAD App with http://localhost:61659/signin-oidc
Update these URLs if you configure the app for production use or If you publish the App to Azure Web App, you should change the Reply URL in both App config file and AAD Application to be <AppURL>/signin-oidc
For example, https://www.contoso.com/signin-oidc or https://Myapp.azurewebsites.net/signout-oidc.
I had a similar problem with a .NET 4.6.1 web application.
I had to configure the Reply URL for my app in azure similar to the accepted answer, however the callback url was different.
Select Azure Active Directory -> App Registrations -> <your app>
Select Settings -> Reply URLs
Add your apps URL + '/.auth/login/aad/callback'
For Example:
https://somesite.azurewebsites.net/.auth/login/aad/callback
Check your redirect uri in your Microsoft sign in page
redirect_uri=https://localhost:8443/login&response_type=code&scope=openid%20profile&state=7GsiHb
And make sure that you have added the same URI to redirect URI list in your registered application (Active Directory -> App Registration -> Your Application). As mentioned in other answers may need to change supported account type as "Multiple Organizations".
Just got the same error. My app is a .NET 5 ASP.NET Core app running in a Linux docker container inside of a web app. Troubleshooting using Fiddler has shown that in calls to login.microsoft.com the value of a redirect_uri query string variable was starting with "http://" and not with "https://" as I would expect despite my attempts to enforce TLS-only on the web app itself. That led to URL mismatch and to the error AADSTS50011.
Setting the environment variable ASPNETCORE_FORWARDEDHEADERS_ENABLED=true on the web app has fixed the issue. Microsoft has documented it here: https://devblogs.microsoft.com/aspnet/forwarded-headers-middleware-updates-in-net-core-3-0-preview-6/
Make sure services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1); must below the Authentication configuration.
services.AddAuthentication(options =>
{
options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
})
.AddOpenIdConnect(options =>
{
options.Authority = "";
options.ClientId = "";
options.ResponseType = OpenIdConnectResponseType.IdToken;
options.CallbackPath = "";
options.SignedOutRedirectUri = "";
options.TokenValidationParameters.NameClaimType = "name";
})
.AddCookie();
I was facing the same error due to having added AddMvc() before the AddAuthentication() extension method.
In some case, azure to use the 'www' on the url, even if you especific the url on the portal without 'www'. Use "https://www.mysite.co/signin-oidc" instead "https://mysite.co/signin-oidc" in your redirectUri variable.
Small thing, but at the Web Tenant, at custom domains settings HTTPS Only option should be turned on depending on URLs used by the site. I had the same problem, as at the login, the redrect_uri=http://sitename was concatenated instead of https. Enabling this option resolved my authentication issue.
If you are signing in from AAD you should use app-base-url/sigin-aad.
If you use React- Native. Able to check the web portal: https://portal.azure.com/.
iOS: {YOUR_BUNDLE_IDENTIFIER}://{YOUR_BUNDLE_IDENTIFIER}/ios/callback
Android: {YOUR_APP_PACKAGE_NAME}://{YOUR_APP_PACKAGE_NAME}/android/callback
pls refer with image below.
enter image description here
The only solution for me: in the Azure portal https://portal.azure.com, navigate to "app registrations" -> select your application -> "authentication" from the left sidebar menu -> "mobile and desktop applications" redirect URIs -> and click "Add URI" -> type the following
ms-appx-web://microsoft.aad.brokerplugin/{Your_Application's_Client_ID}
Example: ms-appx-web://microsoft.aad.brokerplugin/5r3257qe-7jci-3501-38k0-3791h90542m7

Resources