I have a SPA application that I've developed using Auth0 for my IDP. When developing locally, I set the Auth0 Allowed Web Origins settings to http://localhost:8080 and got everything working.
Now I've deployed my app to Azure as a Web App -- so my app is addressed like so: myapp.azurewebsites.net. I've also included a custom domain so that I can access my app like this: myapp.mydomain.com.
I went into my Auth0 dashboard and updated the Allowed Web Origins to include https://myapp.azurewebsites.net and https://myapp.mydomain.com
However, I can no longer get Auth0 to authenticate. When I make the call to the auth endpoint at Auth0, I get a callback to my signin-oidc endpoint with the error
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
My guess is that I'm not getting the Allowed Web Origins correct. What can I do to get this working again?
You are looking in a wrong direction (just like me :) ). Solution is adding web.config to your project. Discussed lot's of time here before.
Angular2 - page refresh 404ing when hosted in Azure
Error : The resource you are looking for has been removed, had its name changed, or is temporarily unavailable
Related
In many cases, Azure B2C send error code and message back to the web app. For example, when you use ValidTokenIssuerPrefixes to define an acceptable Azure AD tenant, and when the user is not from one of the tenants, the following error will be sent back to the web app:
https://[my_web_redirect_uri]/#error=invalid_request&error_description=AADB2C90238%3a+The+provided+token+does+not+contain+a+valid+issuer.+Please+provide+another+token+and+try+again.%0d%0aCorrelation+ID%3a+98d02f12-8df7-49eb-9782-6eb2eaea4e30%0d%0aTimestamp%3a+2022-11-02+16%3a59%3a22Z%0d%0a
When this redirect reaches the web app, it’s up to the web app to display/translate this error. This mechanism is fine when you have a handful of web apps. In my case, I have many web apps that use a single custom sign-in policy. I want to have a centralized page or mechanism to handle the error. I search the internet but haven’t found any answer. Does anyone have a similar concern and solution?
We have two webapi applications (core and support) configured on the same IIS web server running on our local domain. Our users authenticate on the core application using active directory and the core system returns a bearer token. This token is then used to authorize all API calls from our ReactJS client. In addition to the core application, we also have the support web application. Any calls to this system API end points also needs to be authorized.
Is it possible to use the same bearer token issued by the core application for the support application?
We have configured a separate webserver, database server and client to test the process. After building and deploying the two api web applications and the ReactJS client we are able to login via active directory, receive a bearer token and with this token authenticate on both the core and support platforms.
However, when we copy the same files and configurations to our clients server, we get a 401 authorization error on the support domain; the core domain works perfectly.
We have installed SSL certificates in both environments as well.
If we set the support application to Allow all Origins for CORS it works as there is no authorization. However, when we set the origins to the ReactJS and Core api projects we get the 401 error on the support domain.
We did not expect the token from the core application to authorize against the support application. However, this is working within our domain environment and we are not sure why. This has made it even more confusing as to why it does not work in the customers environment.
In case it helps anyone ... The reason this worked for us internally is because we had all web applications running within the same application pool. This meant they shared the same machine key and as such the bearer token from one would be authorized across all. As soon as we moved them into their own application pools we were able to replicate the same issue as the customer (ie. 401 authorization). The fix is to either have them in the same application pool or add the same machinekey to the applications web.config files.
I have an Azure Mobile App service that I use with my (Cordova and Xamarin) mobile apps. The URL for the Mobile App service is https://gonzo.azurewebsites.net/ (not the real URL). I want to create a website (ASP.NET Core 2.0 Web App) that connects to my Azure Mobile App service, just like my apps do. I tried publishing it to the gonzo URL but that overwrote my mobile app service and thus I had to restore it. I’d love to know if there is a way to actually make that work.
My next step was to create the website and use a different URL https://kermit.azurewebsites.net/. I use social authentication for my app mobile service. When I debug it locally against localhost, everything works perfectly. The problem that I’m running into is that when I try to login from the published website, regardless of the auth provider (facebook, Microsoft, google), instead of getting to the login UI supplied by the login provider, I get a 403 with the URL looking something like this: https://gonzo.azurewebsites.net/.auth/login/facebook/callback?code=long-code.
I thought this can be fixed by allowing the kermit origin in my Azure Mobile App service in CORS. I even tried setting CORS to allow all hosts (*) but that didn’t make a difference. Any idea how to make this work?
I want to create a website (ASP.NET Core 2.0 Web App) that connects to my Azure Mobile App service, just like my apps do. I tried publishing it to the gonzo URL but that overwrote my mobile app service and thus I had to restore it. I’d love to know if there is a way to actually make that work.
Based on your requirement, I assumed that you could deploy your NET Core 2.0 Web App along with your mobile app, at this point your two applications could share the authentication. For Detailed tutorial, you could follow Deploying multiple virtual directories to a single Azure Website.
The problem that I’m running into is that when I try to login from the published website, regardless of the auth provider (facebook, Microsoft, google), instead of getting to the login UI supplied by the login provider, I get a 403 with the URL looking something like this: https://gonzo.azurewebsites.net/.auth/login/facebook/callback?code=long-code.
According to your description, you are using the App Service Authentication / Authorization. I would recommend you directly access https://<your-mobile-app-name>.azurewebsites.net/.auth/login/<provider-name> via the browser to make sure you have successfully set up the authentication for your mobile app.
If I understand you correctly that you want to create another Azure Web App to hosting your NET Core 2.0 Website, and your website wants to connect with your mobile app. Here are some approaches, you could refer to them:
For accessing mobile app in the front-end of your .Net Core web app
You could leverage the JavaScript SDK for Azure Mobile Apps in your .Net Core web app to access your mobile app. Details you could follow here. Additionally, if your website would also enable the app service authentication, you could just send GET https://<your-netcore-webapp-name>.azurewebsites.net/.auth/me to retrieve the access_token, then use the Client-managed authentication for logging with your mobile app in the front-end of your netcore website.
For accessing mobile app in the back-end of your .Net Core web app
I assume that your .Net Core web app would also need to enable social authentication via using the App Service Authentication / Authorization, and in the backend of your website you could retrieve the access_token for the current logged user, then you could use Client-managed authentication for logging with your mobile app. The logging request would look like this:
POST https://<your-mobile-app-name>.azurewebsites.net/.auth/login/<provider-name>
Payload: {"access_token":"<the-access-token-for-the-specific-social-provider>"}
Moreover, for retrieving the user logged infos (including the access_token,etc.) from App Service Authentication / Authorization (EasyAuth), you could follow this issue.
I currently have an MVC app that's using the Microsoft.Owin.Security.WSFederation package for authentication with Azure's Active Directory. This lets me use the Authorize attribute on my controllers to redirect users to the Microsoft login site.
I now have the requirement to add access to a WebAPI project that will be hosted on a different domain but will use the same AD store.
I've managed to pull together something using the ADAL JS library provided by Azure but this gives the following process:
user visits site and is redirected to Azure login
user logs in and is returned to site
JS code checks for login and redirects to Azure
user is already authenticated so redirects back to site with token
JS picks up token, stores it, and redirects to the original page
So it works, but involves 4 redirects, which seems like a huge overhead.
I thought that there might be some way of pulling a bearer token out of the authorisation credentials returned when the WSFederation succeeds but I can't see anything like that in the data. And, even if I could, I don't know how I'd be able to then refresh the token from the client script. So I strongly suspect I'm doing something fundamentally wrong.
What would be the best process for sharing authentication between the two sites?
Background:
We have a WebAPI set up with Azure ACS and ADFS for authentication.
Accessing any WebAPI resource through the browser will redirect unauthenticated users to the ADFS login page through ACS. After successful login, the user will be redirected to return Url as setup in ACS along with security token. This works perfectly fine.
Problem:
We are developing a mobile application using the Ionic framework (http://ionicframework.com/). We want to leverage the same ACS and ADFS for authentication which we are using for WebAPI. In this process we are facing the following issues:
Issue 1:
Accessing any WebAPI resource through a mobile application (Ionic, Cordova, AngularJS) redirects the user to ACS and we get below error.
XMLHttpRequest cannot load https://{domainname}.accesscontrol.windows.net/v2/wsfederation?wa=ws…52fitem&wct=2014-10-10T14%3a24%3a34Z&whr=https%3a%2f%2f{domainname}.com. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
Hence we are not able to authenticate any user through ACS with the mobile app.
Issue 2:
Setting Return URL as empty in ACS throws the below error.
ACS90050: No reply address is configured with the relying party principal.
Steps taken so far:
-> We have enabled CORS on WebAPI.
We filed ticket with Microsoft to see if CORS can be enabled at ACS. We got below reply.
ACS does not provide a CORS solution we did research the possibilities. Unfortunately the answer is still: “No ACS does not provide a CORS solution”. That is, ACS does not give us access to the root for a standard cross-domain solution. Further, providing the token is considered HTTPOnly as manipulating the token with Javascript is inherently dangerous.
There is a sample available that may provide guidance if you wish to pursue this path although it is not recommended because of the security aspect. Download the samples found at:
Windows Azure AD Access Control (ACS) Code Samples:
https://code.msdn.microsoft.com/Windows-Azure-AD-Access-0dcde385
The sample under: C#\Webservice\ACS2WindowsPhoneSample may provide some guidance but we would not be able to assist with modifying the sample.