From the service providers documents. Access or bear token is mentioned. It does not say what is the token grant type needed….
I work with SCIM but know some of the auth stuff as a side effect of that. My best effort at answering this is:
Typical implementations of SCIM either provide long-lived bearer tokens or leverage OAuth 2.0.
For long-lived bearer tokens (typically JWT), which can be issued however you prefer - I see them issued via customers making API calls directly or through some form of admin UI.
For OAuth 2.0, typically it'd be either Authorization Code Grant flow or Client Credentials Grant flow.
Keep in mind that "typical" here is in the context of interoperability of applications connected to a major IDP's SCIM client (AAD, Okta, OneLogin, etc). Given the tags on this post mention all of those IDPs, it seemed like a contextual hint.
Related
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.
What is the correct way to provide users with programmatic access to APIs?
I have an application composed of many services (all trusted services, within the same domain, not external applications), and identity service in the same domain.
I would like to allow a user to user a set of credentials to gain access to any of the APIs I provide.
Is it reasonable to think of a user as a client in this case, and use clientCredentials flow to get a token that will be passed to the target API? specifically, is it a good idea automatically assign a clientId and a clientSecret to every user in my system, and allow all users to use clientCredentials flow to request an access token? the access token would then contain all user's claims. If this is a reasonable approach, is there any way to remove the "client_" prefix from the added claims? or is that a bad idea?
This was originally asked here: https://github.com/IdentityServer/IdentityServer4/issues/1877
Sorry I am still very confused, read everywhere telling me oath is a authorisation protocol but it appears using the azure ad oauth code grant, it does promote a login screen to authenticate against the directory, so is it not an authentication process? what is the relationship between the open id connect? thanks!!
the OAuth2.0 protocol has several flows that an identity provider (in your case Azure AD) may implement to support auth.
The Auth Code flow is in fact one of these used by apps to get access tokens for some api. The flow is quite simple, an app redirects the user to the identity providers /authorize endpoint. At this point the user enters their credentials, and the site redirects back to your application with an authorization code and can also issue an ID Token that represents a user (This is the OpenID Connect part). The app takes this code, and POSTs it to the /token endpoint and will be issued an access token and refresh token. With the access token, your app can access whatever api you've requested access for.
For Azure AD specifically, Microsoft has built libraries that handle all these flows and token caching so most of the complexity is abstracted away. There's some simple code samples that you can checkout that you may find helpful. The authentication protocols and scenarios doc for Azure AD may also be really helpful for conceptual information.
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.
I have a REST backend secured with OAuth2 and a mobile application.
I would like to use the Resource Owner Credentials flow to authenticate the user from my mobile application.
Since I must provide a client_id to identify the application which is requesting authentication, how can I prevent a hacker to steal my client_id from my mobile application source code, and how can I revoke it ?
I really would like to know how the official Twitter Android application for example handle this kind of thing.
I know this is a very old post, but I just came across it in an unrelated search and saw it was unanswered.
To quote from the OAuth 2.0 spec,
The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication.
In other words, the client_id is very similar to a username or email. I certainly wouldn't mind if someone found out my email address, even though that is half of the data required to log in and view my emails. To keep to that idea, the client_secret is a password that should be kept private through guarding your source code and sending POST requests only to HTTPS endpoints.
As for revoking privileges granted to clients through those credentials, most (if not all) major OAuth providers will allow you to do something through their OAuth portal. To follow your Twitter example, they have a button on the API Keys page to "Regenerate API Keys." If you are the service provider (I say this because you mentioned having permissions to Resource Owner Credentials) and you don't have a public-facing OAuth portal set up, it would be simply a matter of changing the strings in whatever data-store you use server-side, then making the same change in your client source code.