I am trying to authenticate my Azure Web App. Follow this doc
In my Azure Portal, I've selected "Authenticate / Authorization" for my Web App.
After I configure my Microsoft Account Authentication Settings with Client ID/Key from the App Registration page, I save the settings page and I'll see an error:
The errors says:
Failed to save Auth Settings for WebApp App:
{"Code":"Conflict","Message":"Cannot update the site 'WebApp' because
Authentication / Authorization was configured with an invalid issuer
URL ''. The URL must be well-formed, absolute, and use the HTTPS
scheme.","Target":null,"Details":[{"Message":"Cannot update the site
'WebApp' because Authentication / Authorization was configured with an
invalid issuer URL ''. The URL must be well-formed, absolute, and use
the HTTPS
scheme."},{"Code":"Conflict"},{"ErrorEntity":{"ExtendedCode":"04530","MessageTemplate":"Cannot
update the site '{0}' because Authentication / Authorization was
configured with an invalid issuer URL '{1}'. The URL must be
well-formed, absolute, and use the HTTPS
scheme.","Parameters":["WebApp",""],"Code":"Conflict","Message":"Cannot
update the site 'WebApp' because Authentication / Authorization was
configured with an invalid issuer URL ''. The URL must be well-formed,
absolute, and use the HTTPS scheme."}}],"Innererror":null}
I'm not sure what's the "invalid issuer URL" the issue is referring to.
This issue is not a general issue. This article is absolutely correct.
So I suggest you try to use another location to deploy your Web App and configure the Applicaiton again.
Also, this issue should be temporary, I have reported this.
Hope this helps!
I'm on the App Service team. This is a known issue which we are working to address - the behavior should be temporary. Our apologies for any issues this has caused.
I do not recommend the solution of moving to another region, as this is not guaranteed to work, and sites that do see resolution in this way may break again.
Please find our recommended workaround instructions in my response to this forum post.
For me it worked to add AAD as an auth provider with the default setting even though I'm not using it. I was then able to save my Facebook auth settings. This is a temporary workaround.
This answer from this discussion. Edit field "issuer" not working for me.
Related
I created web app in my Azure account. I have all details like tenat id, client id, client secret etc. While creating I have added uri as https://localhost and I also added scope Data.Read and added Application ID URI. But I can't open above mentioned url. Most possible that I am missing something in my mind and dont fully understand the rule how it should work, that is why I am asking for help. I need this localhost in order to test auth with Azure tokens. What exactly I am doing wrong?
Azure allows http protocol value for only localhost. Remaining all redirect URIs must begin with the scheme https. To use https, you should install SSL certificate.
HTTP: The HTTP scheme (http://) is supported only for localhost URIs and should be used only during active local application development and testing.
I am not sure what error you are getting Azure active directory basically Redirect back to the Redirect URL specified in the request provided to AAD after login using either the /authorize or /token endpoint is what AAD does. If the match is successful, AAD publishes the success response back to the same Redirect URI after successfully authenticating the user. Once the request reaches AAD, it verifies the Redirect URI and compares it with the reply URLs listed in the app registration.
For more information in detail, please refer below links:
How to create Azure Web App | Ciemasen
Localhost exceptions
Redirect URL with http but NOT localhost
I have a use case for a project where I need to automate the creation of Application Registration on Azure programmatically.
I have been using this sample.
error screenshot
We seem to be facing an issue with Authentication for this App Registration code. We have checked the ReplyURLs with the urls in our App Settings. They are the same. What may be another reason for this occuring?
We also found another link on microsoft documentation where this thread seems to be open but have not found a solution there either. https://learn.microsoft.com/en-us/answers/questions/54102/the-reply-url-specified-in-the-request-does-not-ma.html
To deal with this kind of problem, you can try a general solution:
When you visit the application url , you will be redirected to the login page. Decode the authorization request url, you will find redirect_url, copy the value of redirect_url and paste it into the azure portal, and try again.
For the redirect URL, it should start with https, if you need to start with http, you must configure it as http://localhost.
I would like your feedback on the following :
For my AppServices I set Authorization with AzureAD. I get authentication page and redirection to my Appservice is fine.
Then I setup an Azure Front Door which redirect to my AppServices as backend
In browser when I go to https://myfrontdoortest.azurefd.net then i get the AzureAD authentication page and redirection to my AppService is a success(in browser address bar it reads https://myappservicestest.azurewebsites.net).
Now i want to secure my AppServices with FrontDoor as explained MS here https://learn.microsoft.com/en-us/azure/frontdoor/front-door-faq. At this stage I only apply IP restrictions (not yet the X-FrontDoor-ID)
test #1: when i go directly to my AppService like
https://myappservicestest.azurewebsites.net then i get a 403
forbidden access as expected.
test #2: when I go to https://myfrontdoortest.azurefd.net then i get
the AzureAD authentication page. I provide valid credentials and I
noticed that i am redirect to
https://myappservicestest.azurewebsites.net with a 403 Forbidden.
I'm still struggling to fix it.
Is it something i should change in the reply URL to manage IP restrictions ?
Is it something i should change in FrontDoor configuration ?
Your help is very welcome
Because the front door does not have a fixed IP, it is not feasible to set the IP settings in the webapp.
So it is recommended that you still use the official recommendation to add rewrite rules in the xml file.
The article you are looking for is very useful. It is recommended to read it carefully. If you have any questions, you can also raise a support ticket, MS will give you good answer.
I also find this issue, you can refer it.
How do I lock down the access to my backend to only specified instance(s) of Azure Front Door? #36141
Might seem a silly question, but Microsoft's documentation isn't very beginner friendly, I think. It uses as examples "http://localhost:31544" for the sign-on url and "http://MyFirstAADApp" for the redirect URI, but although I understand what a local host is I can't figure out what exactly the numbers on it are and how I define them for my application, and absolutely zero clue of what the redirect URI is supposed to do for a native application and how should I define a URI for my own.
To be more clear on what kind of app I'm trying to add, I merely want to acess the Office 365 management API tools and get some data from it, so I imagine a native app would fulfill my needs for now. Registering the app on Azure AD is required to do so according to Microsoft's documentation.
So expanding on the title, how to define an URI for my native app is what I would mainly like to know. Some further clarification on what exactly is the purpose of this URI as well as to how to use and/or define a localhost URL for an Web app would also be much appreciated.
I know this is ancient, but I don't see a satisfying answer here, and maybe someone will come across this and find it useful. To answer the question asked, unless you're going to work outside of the default MSAL handling of the server responses, and I don't expect you would from your description, I'd just go ahead and use the default:
https://login.microsoftonline.com/common/oauth2/nativeclient
When you go into the Azure AD portal, go to your application and, from the Overview, select the "Set RedirectURL" option, you'll add a platform and select the "Mobile and Desktop Applications" and you'll be provided with the choice of 3 URLs to choose from. My understanding is this is just there for custom handling of authorization tokens and is telling MS where to send those tokens. The MSAL library functions seem to use this link as well, so they're probably handling this in the backend.
I agree with the OP though, the MS docs are severely lacking for newcomers and I wasn't able to find an end-to-end description of what needs to happen to get, in my case, a desktop application to send email through Office365 using 2FA. I would forge ahead as best I could until I hit the next error, then explore that, sort it, then slam into the next one. Rinse and repeat. This was made extra tedious as I had to go through a 3rd party IT group to get the 2FA access codes every time I wanted to test.
Best of luck, hope this helps someone!
how to define an URI for my native app is what I would mainly like to
know.
You should provide a Redirect URI that is unique to your application as it will return to this URI when authentication is complete.
In your application, you will need to add a class level variables that are required for the authentication flow, include ClientId and Redirect URI.
Here is the diagram:
Native application makes a request to the authorization endpoint in Azure AD, this request includes the Application IP ,Redirect URI and application ID URI for the web api.
After user signed in, Azure AD issues an authorization code response back to the client application's redirect URI. After that, the client application stops browser interaction and extracts the authorization code from the response.
Then the client app use this code to sends a request to Azure AD's token endpoint. upon successful validation, Azure AD returns two tokens.
Over HTTPS, the client app uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. The web API then validates the JWT token, and if validation is successful, returns the desired resource.
More information about it, please refer to this article.
For native you can set redirect to be equal to the Application ID URI, which now defaults to look like //app:{ApplicationId}
Redirect uri be starts with SSL URL, so select your project, enable SSL URL and use this auto generated SSL URL (for example : https://localhost:port#) as redirect uri , same to be updated in the azure app registration as additional redirect URIs
I have scenario where we use Thinktecture Identity Server (IdSrv) as both an R-STS and a IP-STS, as well as a O365 / WAAD tentant as an additional IP-STS. The user choose which Identity Provider to use via the Home Realm Discovery functionality in IdSrv.
Now, implementing a unified WS-Federation wsignout from the RP, is difficult, since I can't get the signout process to work properly against WAAD (Against the Thinktecture IP-STS it works fine);
Sorry, but we're having trouble signing you out.
We received a bad sign-out request.
If you wish to sign-out, please click the following link.
ACS20028: The requested redirection URL is invalid.
Well, the wreply URL parameter points to the RP, which the WAAD instance has no knowledge of.
If I try to follow the Sign-Out link, I get
Sorry, but we're having trouble signing you out.
We received a bad request.
ACS20026: The wtrealm parameter is missing or incorrect.
I've tried to modify the URL directly so that its wreply points to the IdSrv (which really is an RP of the WAAD), but I can't get it to work.
Has anyone gotten this to work?