I have Registered two apps in Azure AD; One being the Server and the other being the Client as one set. There are two sets created; One set for Production and the other being for UAT. Client Apps are types of "Web" and none being as SPA.
Production Server App is almost a clone of the UAT Server App. And Production Client App is almost a clone of a UAT CLient app.
Consumers use Client Apps to get tokens by using the OAuth 2.0 token endpoint (v2) https://login.microsoftonline.com/[--Tenant--]/oauth2/v2.0/token as Client Credential Flow with a Secret. The token generated is used as a bearer token to Authorize my Web API.
On the Production Client App, it returns an error when retrieving Token from Token endpoint and it read as:
AADSTS9002326: Cross-origin token redemption is permitted only for the 'Single-Page Application'
Whats Bizzare here is:
Production Client App can get Token from Public Network (Internet), but not in Internal Network (Having Internet access)
UAT Client App produces Tokens from Public and Internal Networks (Having Internet access).
With such facts, it's not rational to say that there is a network restriction in the Production Consumer site. I am clueless on why App is not producing tokens in Internal networks but in Public networks, whereas the UAT Apps have no issue in producing Tokens irrespective of the environment.
This case almost elaborates my case but I have checked mine, where Client App is Public and Server App is Private.
Where to search? What areas to looking to?
In case someone else encounters this error, check the URIs type in the Manifest file to be Spa and NOT Web. Even if you have set the platform in Authentication to Single-page applications, the URIs type might still be set to Web which will cause this error.
Related
We have a corporative KeyCloak server which sits on Azure Account “A”.
We are now developing an ASP.Net Core Application that is on Azure Account “B”. This application is behind an Azure WAG.
The users access the application from the internet through the WAG and hits the Azure WebApp:
"https://myexternaldomain.com" => "https://myinternalazuredomain.azuresites.net".
As expected the users is redirected to Keycloak corporate server ("https://sso.corporate.com"). Once the user is logged in, he is being redirected to the callback address "https://myexternaldomain.com/oauth/callback".
At this moment we get a exception “Correlation Failed”, “Unknown Location”.
Architecture and Exception below:
Architecture and Exception
We believe that the problem is related to the address the users is using ("https://myexternaldomain.com") being different from the actual address the server is on ("https://myinternalazuredomain.azuresites.net"). And this makes even more sense when we take into account that it was working fine before the addition of the WAG.
Can you guys give us some insight?
Thanks
Best Regards
Take Care
There were a couple things that needed to be done to get KeyCloak + AppService to work in this scenario.
We had to add the same Certs to Wag and AppService, so KeyCloak would understand it as the same request.
Also the network team misconfigured the WAG, and some of the headers were not being forwarded, and KeyCloak would not accept the given Auth Token as valid for the current request.
I have a two slots for mobile app service at Azure: production and development. Also I have a client app that can work with this mobile service. Application version hosted at production slot does not contain authentication. Application version hosted at development slot has authentication and it works well. So, my client app can get authentication token and access protected API, and work with service hosted at development slot. When I swap this slots, client app still can get authentication token, but can't access protected API. I getting error 401 unauthorized on any attempt to call API using acquired token.
I'm using a custom authentication as described in docs
Both slots is identically configured: authentication: enabled, action to take when request is not authenticated: allow anonymous requests, authentication providers: disabled. As far as I can understand the one and only difference between those slots is URL. It looks like when the url of service is changed, it starts to generate invalid tokens.
That can be a cause of this behaviour?
For anyone else coming across this question, there are a few additional things to consider when using Azure authentication and slot swap. First, the Azure team has corrected the hostname issue, so all slots have the same hostname (you can verify this in the Environment settings for each slot). Tokens generated on one slot are now completely valid on all other slots.
HOWEVER, when a token is generated, it is stored in a folder on the hard drive of each slot, and that folder is not sticky to a specific slot. This means that if you have client users using a token for your production slot and you swap production and staging slots, that client's token WON'T be valid anymore (because their token reference that was on the production slot is now on the staging slot).
This may or may not be an issue for your app. If you require users to log in frequently, then they may not even notice the extra need to login. If however you have long lasting tokens (like most social networking sites) then this can cause some headaches.
One of the parameters that involved in token creation process is hostname. In my code hostname value was provided from MobileAppSettings. The problem was that MobileAppSettings return the hostname value of development slot after the slots swap, so the generated token is invalid. Service restart fixes this behaviour.
Here is what I am trying to accomplish -
A native application which is going to be run on a system where I cannot involve the user to login but I want to access web services secured behind AAD using a bearer token. There are two options -
Use a certificate based flow (which I want to avoid for few reasons
specific to my project)
Use the client secret
Issue I am running into:
When I call acquiretokenasync using the Native AAD application's client ID and a client credential built using the AAD web application's (which the native app has permissions to) client secret, I get the following error -
{"AADSTS70002: Error validating credentials. AADSTS50012: Invalid client secret is provided.\r\nTrace ID: f52cc954-2674-47ee-9a7b-094451b05c7c\r\nCorrelation ID: 1ba8ac64-cc4a-4ff7-83d6-a333504459d6\r\nTimestamp: 2016-08-20 01:45:08Z"}
So given that the client secret is indeed correct (which I am positive about), what could be the real issue behind this error?
Thanks in advance for your help :)
You can't use the native application client ID and web application client credential (client secret). The native application has no associated secret, only the web application has. Native applications are assumed to run on insecure hosts, such as the desktops and smartphones. Client secrets would become too fragile.
For more information on how to authenticate a native application and access resources, take a look at these articles:
Authentication Scenarios - Native Application to Web API
Developing Native Client Applications
There are two types of application which we can register in Azure Active Directory.
Select Native for client applications that are installed locally on
a device. This setting is used for OAuth public native clients.
Select Web app/API for client applications and resource/API applications that are installed on a secure server. This setting is
used for OAuth confidential web clients and public user-agent-based
clients. The same application can also expose both a client and
resource/API.
Native applications are public clients in OAuth2 parlance. Those apps are meant to run on a device and aren't trusted to maintain a secret - hence, their entry in the directory does not have the corresponding property. Without a secret, there is no way to assert the identity of the app - hence such apps cannot gain app level permissions and the portal UX reflects that. Conversely web apps are, again in OAuth2 parlance, confidential clients. They can get delegated tokens for their users, but they can also use client credentials to get tokens as themselves. Native apps can obtain tokens for the user via the OAuth2 authorization grant.
Refer this article further.
This may sound a silly question...
I want to authenticate an end user that connects to a webapi service against Azure AD.
The Web Server (where the webapi service is hosted) is located in a zone without internet connection due to security reasons, behind a reverse proxy.
The client (end user) is at home with internet (of course) and connects to the webApi service through the reverse proxy.
Does all/any of the available authentication methods against AZURE AD require that the server that hosts the webapi service has Internet connection?
Thanks
You can do this! :) As long as there is internet between the client and the identity provider (AD), you can always obtain a token and send it to the API - the API does not need a live connection to authenticate, it just needs to validate the token supplied by the client in the call.
The only tricky part is that today's OWIN middleware automates the acquisition of the token validation parameters by reading a discovery document hosted on Azure AD. That is clearly not an option in your case, but what you can do is to acquire that document out of band and use the info you find in there to initialize the middleware manually. Unfortunately we don't have samples that show how to do this, but let me see if I can get a snippet to post here.
I'm trying to design a green-field project that will have several services (serving data) and web-applications (serving HTML). I've read about microservices and they look like good fit.
The problem I still have is how to implement SSO. I want the user to authenticate once and have access to all the different services and applications.
I can think of several approaches:
Add Identity service and application. Any service that has protected resources will talk to the Identity service to make sure the credentials it has are valid. If they are not it will redirect the user for authentication.
Use a web-standard such as OpenID and have each service handle it own identities. This means the user will have to authorize individually each service/application but after that it will be SSO.
I'll be happy to hear other ideas. If a specific PaaS (such as Heroku) has a proprietary solution that would also be acceptable.
While implementing a microservice architecture at my previous job we decided the best approach was in alignment with #1, Add identity service and authorize service access through it. In our case this was done with tokens. If a request came with an authorization token then we could verify that token with the identity service if it was the first call in the user's session with the service. Once the token had been validated then it was saved in the session so subsequent calls in the user's session did not have to make the additional call. You can also create a scheduled job if tokens need to be refreshed in that session.
In this situation we were authenticating with an OAuth 2.0 endpoint and the token was added to the HTTP header for calls to our domain. All of the services were routed from that domain so we could get the token from the HTTP header. Since we were all part of the same application ecosystem, the initial OAuth 2.0 authorization would list the application services that the user would be giving permission to for their account.
An addition to this approach was that the identity service would provide the proxy client library which would be added to the HTTP request filter chain and handle the authorization process to the service. The service would be configured to consume the proxy client library from the identity service. Since we were using Dropwizard this proxy would become a Dropwizard Module bootstrapping the filter into the running service process. This allowed for updates to the identity service that also had a complimentary client side update to be easily consumed by dependent services as long as the interface did not change significantly.
Our deployment architecture was spread across AWS Virtual Private Cloud (VPC) and our own company's data centers. The OAuth 2.0 authentication service was located in the company's data center while all of our application services were deployed to AWS VPC.
I hope the approach we took is helpful to your decision. Let me know if you have any other questions.
Chris Sterling explained standard authentication practice above and it makes absolute sense. I just want to put another thought here for some practical reasons.
We implemented authentication services and multiple other micro services relying on auth server in order to authorize resources. At some point we ran in to performance issues due to too many round trips to authentication server, we also had scalability issues for auth server as number of micro services increased. We changed the architecture little bit to avoid too many round trips.
Auth server will be contacted only once with credentials and it will generate the token based on a private key. Corresponding public key will be installed in each client (micro service server) which will be able to validate the authentication key with out contacting auth server. Key contain time generated and a client utility installed in micro service will validity as well. Even though it was not standard implementation we have pretty good success with this model especially when all the micro services are internally hosted.