I have registered two applications in Azure AD, a .Net core web API and a single page react application. I configured these applications to get the id_token for the react client application and an access token for consuming the web API when the user signs in to the client application. I need to send user-specific information to my API when the user signs in (I need to get a unique id from the token to identify the user). Some document says we can't send the id_token to the API since it is issued for the client application. and some says we can't send the user-specific information via access token since it should be used for authorization purpose only.
Is there any other way to solve my problem?
In the context of Open Id connect, is it ok to send user-specific information via access token? I want a unique id from the token and store it in my system to identify the user. if it is ok to use the access token, Which claim is best suited for this purpose (sub or oid)?
You are right that you should not send the id_token to the API. One option is to include the necessary user information as claims inside the access token. Alternatively you could try to ask AzureAD for the user details when the API receives the access token. Azure for example provides the UserInfo endpoint for this.
See this page Microsoft identity platform UserInfo endpoint
Related
We are looking for a way to retrieve the JWT token specific to the current logged in user of Dynamics 365 CE. This is required for one of our integration to pass the JWT to the legacy system using APIM & logic app a middle layer. Below is the entire flow of the integration for which we need this.
CE user will call APIM url(which masks the logic app of http trigger) using some action in the form.
I have enabled the oauth2.0 in the APIM settings and enabled the validate jwt policy.
In CE JavaScript code while calling the APIM URL , we are sending the jwt (that we received using the client id & secret configured in our AAD). This is authenticating the validate jwt policy and oauth 2.0 setting.
The same jwt token we need to pass to the logic app and subsequently to the legacy API using an HTTP action.
Now, we are looking for a way to send the jwt token of the logged in user in CE to the APIM url rather than the one generated using the client id & secret.
Please let us know if this is achievable or we need to change our design.
The whole discussion with customer started about securing the data access in the legacy system. If we use the client id & secret jwt, it is tied to one permanent service account(with system admin role) in CE.
We want to avoid that and retrieve the data from legacy system to which the CE logged user might have access to as per the AAD permission & roles. Please give your suggestions here.
As shown by many samples I have two AAD application registrations, one for my javascript-based front end, and one for my JSON-only web APIs.
If I fully trust my client AAD application, why does AAD require me to create a second AAD application for my web APIs?
For example, assuming I add specific roles to my client AAD application, if client signs in with AAD and gets an id token and access token containing my roles, it only needs to send the access token to my APIs. The API only needs to crack the JWT, validate the audience, issuer, tenant, roles permissions, and signature. In this world, no client secret is needed in the web APIs, a second AAD application registration not needed, and still no call to AAD from my APIs. Unfortunately, without two AAD applications, I cannot figure out a way to have AAD include roles into my access token.
If I didn't fully trust the issuer from mucking with claims, I can see why I would need two AAD applications and a client secret. But since I do trust my AAD application and the signature of the JWT, why the extra complexity? Or maybe there is a way to do this that I haven't found?
Thanks!
Responding to Marc here because just not enough characters in the comments field -- The sample you referenced is an excellent sample, specifically the JavaScript one calling the Web API. It is what I am doing right now in fact. However, the problem is that Web API in the sample is open to anybody who has authenticated on the tenant. I need to secure the Web API down to certain individuals in the tenant, and simply checking the client/app id is not sufficient as anybody who can create an AAD app can fake it.
So what I need to do is have roles added to the the access token so I know that my application authenticated the user, and that user has been granted the required roles. For example, here is a Microsoft sample. And even here a Microsoft video walking through the process.
If I don't have two AAD applications w/client secret, the roles claims is never provided in the access token. It is always provided in the id token, but not the access token.
I feel like I am missing something obvious here. If AAD would just put the roles I requested into the JWT when I authenticated against it, and I validated its signature, audience, issuer, and roles, I wouldn't need any of this extra complexity?
Ah, I think I understand where you are going: you would like to control which users can access an API, no matter what client app they are using to access the API with. That's a function of the API - you cannot control that through AAD. In AAD you can control which users can access which applications (UI) using either user access restrictions (enterprise tab) or role-based access. However, access to an API is controlled in AAD at the calling application level via scopes. APIs are never accessed directly by users but only by other apps so controlling access permissions at user level would cause admin havoc. So, you can control what permissions a user has in the app they are using and you can control what permissions that application (client) has in other applications (APIs, resource servers) it is using.
In other words: role is about user access to UI, scope is about one apps' access to another.
App secrets provide added security for getting tokens - they have no bearing on what permissions are included in the token.
Can you provide a link showing that two apps are needed? That should only be the case if the API you want to call is not provided by the web app which served the JS to the browser. None of the 'official' samples require you to register two apps (Graph API, used in some of these samples is a separate API and it is already registered). A problem with tokens passed from the browser is that they were acquired by a public client, not using any secrets apart from user creds. Therefore, they are easier to steal and re-use. Your own back-end app may want to use a secret to get its own token (extension grant) to call yet another API using a token that does not reside in a public client.
I am switching my application from Azure Active Directory authentication to authentication with Identity Server (using Azure AD as external auth). The authentication and authorization part is implemented and my web API successfully validates token and give me what I'm asking.
Our application also uses external APIs, such as Graph API and SharePoint Online which require Azure AD token. E.g. when I go to https://graph.microsoft.com/v1.0/me from my JS application with token that I get back from Identity Server, Graph API response is
401
{
"error": {
"code": "InvalidAuthenticationToken",
"message": "Access token validation failure.",
"innerError": {
"request-id": "ce7651bb-5dc4-49e9-90ff-02df440ed4ad",
"date": "2017-08-11T08:53:12"
}
}
}
I expected that because Identity Server is giving me his token, and not passing the existing token that is provided by Azure AD. I copied all the claims from Azure AD token into identity server token, but no changes.
What would be the right approach to enable my application to continue using APIs which require Azure AD token?
EDIT:
What I'm hoping for is this.
Click login button on Js (or any other client app)
Redirect to Identity Server login screen
Click on Azure AD external auth
Redirect to Microsoft login page and enter your credentials there
Redirect to Identity server app
a. I started Fiddler and see that "Microsoft" redirect to {IdentityServerAppUrl}/signin-aad (I suppose this is because I configured CallbackPath property on OpenID Connect options). This request carry a cookie idsrv.external. I'm not sure but I think inside is access token from Azure AD. I don't know how to decode this. I tried with base64, but it is not working.
b. When this request is finished redirect is made to {IdentityServerAppUrl}/account/ExternalLoginCallback. In this action method I check with debugger all fields and data in request but I can't find token from AAD. I'm hoping to get token and put it in additional calims.
Identity Server app redirect to JS client app with its own token and additional claim that contains Azure AD token that is valid on graph API and SharePoint.
First I would like to locate Action method or middleware that handle {IdentityServerAppUrl}/signin-aad?
Second, is there any way to get token from Azure AD or any other external provider inside {IdentityServerAppUrl}/account/ExternalLoginCallback Action method?
Be aware that I'm new to this kind of stuff and maybe I'm totally wrong with this thinking.
I manage to do Azure AD authentication without Identity Server, but know we have request to have multiple external providers and I'm hoping to handle all authentication in one app. If one day I get request to have additional external provider I need to add to just in one place.
You need to retrieve an access token from AAD for the Graph API - how that exactly works, check the Microsoft documentation.
Once you have that access token, you can return it as a claim in either the IdentityServer identity or access token (depending if you want to make it available to your front or back-end).
You can also try that first in a simple MVC app to remove the moving partsy - and once you have the AD part working, move your code to the app using the identityserver middleware.
I am also looking for an answer to this question. However, I think it should work a bit differently. IdentityServer gives you a JWT that you can use to authorize to the recources that make up your app. E.g.: yourAPI-1 and yourAPI-2. With the JWT you can pass on the identity. Microsoft Graph is an external resource. Therefore we would need the access token form the Graph API as a claim or external resource, same way as you'd receive an access token for an internal resource.
I would guess that there should be a way of forwarding whatever information you get from the identity provider (Azure AD) to IdentityServer for your client (JS app) to pick up. I am facing the same problem here.
There is another thread about this topic that caught my attention which I will look into. It requires to build your IdentityServer from the source with a few modifications: ASP.NET Identity (with IdentityServer4) get external resource oauth access token
I will let you know what the outcome is and push it to a git repo that you can use if it works:
I'm having I think, a misunderstanding of concepts related with Oauth2 protocol. Right now I have 3 applications:
Frontend developed in React
OAuth2 server developed in Golang (not finished)
Another backend app, let's call it: Bussiness Logic app
At first, the user from react can login in the system using the OAuth2 server, the OAuth2 server sends the token and everything's perfect.
Now, when from the the react app some request is send to the Bussiness Logic App the token is also send in the headers. My question is: having the token, should I be able from the Bussiness Logic App to get information fo the user making a request to the OAuth server? is it allowed in the OAuth protocol?
The thing is that I need to know in the Bussiness Logic App which user is logged in, if it's not allowed, how should I fix it?
No.
OAuth 2.0 NOT an Authentication protocol.
If you need Identity Information you need to use OpenID Connect (which is built on OAuth 2.0)
With OpenID Connect you are provided both an Access Token and an Identity Token. The Identity Token will contain "basic" profile information about the "user". The Access Token may be used to obtain more detailed information about the user from the userinfo_endpoint.
Background
We are developing a multi-tenant SaaS product in Azure which has an AngularJS front-end and Web API back-end. We use Azure AD for authentication and have hooked it up with ADAL JS (using the OAuth2 implicit grant). Being a multi-tenant application, we allow customers to authenticate against their own Azure AD (which may or may not be connected to an on-premise AD).
So far this all works nicely. ADAL JS takes the user to the Azure login page and once the user has authenticated, an OAuth2 token is issued. This JWT token is then sent with all API calls as a bearer token where we have our own claims transformation process for mapping the incoming claims from Azure to our application claims.
Rather than specify individual users in the claims transformation process, we try to do it by AD groups. This allows our customers to have security groups in their AD and then our application will use that to map to the correct application claims.
The problem
The JWT token we receive does not contain a groups property, despite having set groupMembershipClaims to SecurityGroup in the AAD application manifest. I have since read in this tweet from Vittorio that
The implicit grant will NOT send those claims, as it returns the token in the querystring - it's easy to blow past max length
Upon further investigation, I also found this StackOverflow answer from Vittorio that says
I verified and in the implicit grant case you will receive groups always via the overage claim. Please refer to https://github.com/AzureADSamples/WebApp-GroupClaims-DotNet/tree/master/WebApp-GroupClaims-DotNet - it will show you how to process the overage claim to retrieve groups.
I had a look at the JWT token and it does not include any overage claim (identified by _claim_names and _claim_sources). I'm definitely a member of two groups in my Azure AD.
I also now appear to have two conflicting statements about whether it is possible to get group information (whether directly or indirectly) in the implicit grant token.
Question 1: Should I get an overage claim that I can use to get group information? If so, do I need to do anything to ensure that claim gets sent to me?
Graph API
Whether I can get an overage claim with a link to the user in the graph API or whether I have to manually craft the link to get the user's groups, I'm still a little unsure how I authenticate with the graph API.
I need to contact the graph API from the back-end after receiving a request with a bearer token (from ADAL JS).
Question 2: Can I send the same bearer token to the graph API to read that user's directory information? Or do I need to authenticate directly from my application to the graph API tenant in the context of the application rather than the user?
apologies for the confusion here. I will double check the statement about the overage, but in any case - for the sake of unblocking you quickly, let's assume that you need to get the groups manually without the aid of the overage claim. You cannot reuse the token you send to your Web API. That token is scoped to your app, and any other recipient will (or should) reject it. The good news is that the flow through which your backend can request a new token scoped for the Graph is easy to implement. See https://github.com/AzureADSamples/WebAPI-OnBehalfOf-DotNet - the details in your case are a be a bit different (your web API has the audience == clientid of your app) but the topology and the code/calls involved are exactly the same. HTH! V.