Azure AD authentication for multiple domains - azure

I have a cordova application which I am authenticating using azure AD cordova plugin and it all works fine. But now I am integrating services published in another domain and I am unable to authenticate these services using the mobiletoken generated after authentication. Can someone guide me how to secure multiple domain APIs published as Azure web APIs and use token to access the secured APIs.
I have tried to modify the secured settings in azure portal of one of the APIs by including reply URLs for both the APIs
When I include the token in the header of the ajax requests going into 2nd domain endpoints, I just get "unauthorized" error.

It sounds like you're able to get an access token in a Cordova setting and you're having issues accessing multiple web apis after the user has logged in.
The authentication protocol I would suggest you utilize is the on-behalf of flow which is doocumented here : https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow
Per the summary :
The OAuth 2.0 On-Behalf-Of flow (OBO) serves the use case where an application invokes a service/web API, which in turn needs to call another service/web API. The idea is to propagate the delegated user identity and permissions through the request chain. For the middle-tier service to make authenticated requests to the downstream service, it needs to secure an access token from the Microsoft identity platform, on behalf of the user.
This is to get a new access token with the right audience to gain access to web api 2.

Related

Azure APIM & oAuth 2.0 with Multiple Clients

I am finding it hard to understand how I can differentiate multiple client applications using oAuth 2.0.
Using APIM I mapped my backend webservice to Azure API Gateway Service URL. I have configured Oauth 2.0 with grant type as client credentials because its a service to service integration.
In Oauth registration, I have mapped my client and backend app Id's with secret keys - (OauthSample1.0).
It doesnot have the provision to configure multiple clients for the same backend service.
And, in my API, i can add only one Oauth reference - (OauthSample1.0). Even if i would go ahead and create multiple Oauth 2.0 references for different clients, technically it cannot work with the API configuration.
This means I can have my API validate only one specified client using one oAuth 2.0 reference.
If I want my API to be accessed by different partners / Client applications, my understanding is that I would need to create different Clients in Azure AD. But unfortunately not able to design the solution here.
The official doc for protecting your API using OAuth 2.0 covers the steps required in detail.
To summarize, the steps are
Register an application to represent the API
This app is setup to expose an API
Register separate applications to represent each of your client applications
These apps would also have a secret generated for the client credential flow
These apps would have been granted access to the exposed API
Setup a Validate JWT policy to pre-authorize requests.
Your clients would have to get the token using the client credentials flow before making the requests.
Also, if your clients are services that directly access the APIs, then you could setup app roles that show up as Application Permissions instead of Delegated Persmissions.

Call web API from MVC site that is authenticated with Facebook

I'm not an expert in security, so I would like to validate the options here because I'm a bit lost in all the possibilities.
I have an ASP.NET Core MVC web application, and added Facebook authorization to it (there will be others as well, like Microsoft Mail, and integration with an Azure AD). So users currently can click the 'Log In' button, then click the 'Facebook' button; they redirect to Facebook, enter their credentials, and finally come back to my site where they are authenticated. This works fine, and in the claims I receive nameidentifier and email address.
Now I want to add a ASP.NET Core Web API, which is called by the MVC site (and later by other consumers).
As I have to implement my own authorization mechanism in the web API, I was thinking on passing the authentication token from MVC site to the web API, so that in the web API i know the authenticated user, and based on the nameidentifier I find in the token, I handle authorization for this user.
Is the solution that I propose here feasible for my scenario? Or do you handle this kind of situation typically in another way? Demo applications that I can have a look at maybe?
Is the solution that I propose here feasible for my scenario? Or do you handle this kind of situation typically in another way? Demo applications that I can have a look at maybe?
Yes, you could use Oauth 2.0 on-behalf-of flow to achieve your idea. The OAuth 2.0 On-Behalf-Of flow serves the use case where an application invokes a service/web API, which in turn needs to call another service/web API. The idea is to propagate the delegated user identity and permissions through the request chain.
Here is work flow:
1.The client application makes a request to API A with the token A (with an aud claim of API A).
2.API A authenticates to the Azure AD token issuance endpoint and requests a token to access API B.
3.The Azure AD token issuance endpoint validates API A's credentials with token A and issues the access token for API B (token B).
4.The token B is set in the authorization header of the request to API B.
5.Data from the secured resource is returned by API B.
You can refer to the code sample: Calling a web API in an ASP.NET Core web application using Azure AD.

Aquiring JWT-Token from AAD via Azure API Management Gateway

I have an API hosted in Azure (Web App). This API can't be accessed directory by every client (IP Restriction), and I am willing to use APIM to protect it.
Users will call the APIM-Gateway and the gateway should responds appropriately.
One big problem is authentication: I am protecting this API (The Backend API and not the APIM-Gateway endpoint) with AAD.
So users should authenticate themselves against AAD and access the resources with no direct access to the backend.
Is it possible to implement such a scenario?
If you're fine with users authenticating against AAD then it's perfectly supported. With that model APIM may be used to just pass-through user requests to backend or you could use validate-jwt policy somewhere in request processing pipeline to validate users' tokens and authorize invoked actions.
APIM's authorization servers feature may be used to document that your APIs require AAD token from certain server. If this is done test console on developer portal will show controls to simplify getting token to make test calls to your APIs.
Normally APIM requires clients to pass subscription keys to authenticate and authorize calls. But if you're relying on AAD that may be not something you want - then you can use Open product to make your calls anonymous to APIM. validate-jwt policy can still be used to require certain token to be present with request.
There are various ways you can ensure that your backend is reachable only via APIM:
Shared secret - set a special header in APIM policy and check it's value on backend.
Client certificate authentication - APIM may be set up to attach client certificate to each request to backend that you will check at backend side to make sure that this is APIM making a call.
VNET - APIM can join your VNET, while backend may be setup to accept calls only within VNET making it possible to be called only through APIM.
I have used below approach in my recent project and used jwt validation to validate oauth2 token in policy
Follow Microsoft document link https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad.
Here is a quick overview of the steps:
Register an application (backend-app) in Azure AD to represent the API.
Register another application (client-app) in Azure AD to represent a client application that needs to call the API.
In Azure AD, grant permissions to allow the client-app to call the backend-app.
Configure the Developer Console to call the API using OAuth 2.0 user authorization. (optional)
Add the validate-jwt policy to validate the OAuth token for every incoming request.

Xamarin.Forms Azure Mobile App Services Offline Sync without hosting Web Api on Azure

At the moment I have an app that uses Azure Mobile App Services to manage offline sync as well as authentiation. Authentication is done with Azure Active Directory and the way that I have it setup is that the web api is published as an app service on azure and it is configured as an app in the Active Directory Section. The Native App which is done in Xamarin.Forms is also configured in azure so that whenever the app makes a request it can properly authenticate with the api.
What I want to do now is take this web api and put it in an on-premise server. I have to do this in order to optimize some latency issues that I am having when retrieving data. My question is how can I use the offline sync functionality with the api in and on-premise server while still using Azure Active Directory as my authenticator.
Where I am mostly having issues is with the authentication part of the implementation.
I appreciate any help.
According to your description, you are using Authentication and authorization in Azure App Service for build-in authentication without having to change code on the app backend. Authentication / Authorization for Azure App Service (Easy Auth) is implemented as a native IIS module that runs on Azure side, details you could follow Architecture of Azure App Service Authentication / Authorization.
My question is how can I use the offline sync functionality with the api in and on-premise server while still using Azure Active Directory as my authenticator.
AFAIK, we could not install the native IIS module easyauth.dll. Based on your scenario, you need to do some additional work to achieve your purpose.
For .NET backend, you could use Microsoft.Azure.Mobile.Server.Authentication OWIN middleware to validate tokens (the JWT authenticationToken). Note: This middle-ware is used to local development and debugging the mobile app .net server on your side.
For Client-managed authentication flow
You need to add a additional endpoint in your app backend for receiving the access_token returned by AAD to the client user, then your app backend would use the access token to access the signed-in user endpoint (e.g. https://graph.windows.net/me?api-version=1.6) to retrieve the user basic info, then encode user info into a JWT token and return to your client. Here is an example for generating the JWT token, you could refer to it.
Note: The App Service build-in authentication would also generate the JWT authenticationToken to the mobile client. For this approach, you retrieve the signed-in user information manually and follow the custom-auth to generate the token by yourself.
For Server-managed authentication flow
You need to provide a login endpoint and redirect the user the AD authorization endpoint, then your app backend receive the authorization_code and retrieve the access_token, then access signed-in user info via the access_token, then encode the user claims to JWT authenticationToken and redirect the token (e.g. https://{your-domain}/.auth/login/done#token={the-json-string-of-LoginResult}) to the client user.
Note: The above two approaches are used to implement some similar features from Easy Auth in your on-premise server.
Moreover, you could just use the middlewares UseWindowsAzureActiveDirectoryBearerAuthentication for AAD v1.0 endpoint or UseOAuthBearerAuthentication for AAD v2.0 endpoint to project your web API instead of the authentication middleware provided by Microsoft.Azure.Mobile.Server.Authentication. Here are some tutorials, you could follow them:
Azure AD .NET Web API getting started
Secure an MVC web API with AAD v2.0 endpoint
For this approach, your mobile client could leverage the ADAL or MSAL client library for acquiring the token. Then when you implement the MobileServiceClient instance, you could specific a custom DelegatingHandler for adding the authorization header with the value to the access token you acquired as the bearer token against your Web API backend. Details you could follow the How to: Customize request headers section under Working with the client SDK.

Single Sign on - Multiple application azure AD B2C

I am trying to have two applications(app1 and app2) in Azure
AD B2C, which is configured for Web api and another application that is configured for mobile app.
I need my mobile app to talk to app1, get the access token, using the app1's application-id and scope. Then use the access token got from app1 to communicate with app2. I enabled SSO in tenant level in the policies but it still says "Authorization denied" for the access token provided.
How can I reuse the access token got from one application to be used in another application.
We have been trying to get through this limitation (or function as designed for security) of B2C AD from weeks.
However, Microsoft does not support it.
We did not want to display MS login page to mobile user on mobile login screen (UX gets compromised). But MS says there is no way possible to avoid it. See response from MS on support ticket.
For more information: Azure AD B2C: Requesting access tokens
You will also benefit reading authentication scenarios supported. We are after something similar to this what they call "Daemon or Server Application to Web API".
In this diagram, Server Application = to mobile application in our case. However you will notice that in this scenario it is assumed that the user is already authenticated (via interactive flow).
We tried to act smart, thinking we can write a Auth web API which mobile will hit to obtain token and then pass this token to our business logic API (secured by B2C AD). We obtained access and refresh token somehow, however the test web app (mobile app) when pass this access token to our business logic API, it fails to validate the token. B2C AD comes fighting for it. Our analysis is not yet complete.
However, I am certain what we are trying to accomplish is not supported in B2C AD.
Hope this helps (I would actually advise you to look for other solution). I will be happy if someone can suggest a way to solve this obvious business problem.

Resources