When using Azure AD client credentials flow, should the oauth2 endpoint (of azure ad) produce a bearer token if the client application has NOT been granted permission to access the requested resource? I was certain it used to error in this case, but I'm now seeing different behavior (a valid bearer token is now provided even if the client application does NOT have permission to the resource application).
We have always allowed tokens to be issues between two services when using the client credential flow. This scenario is basically S2S between Daemon Services.
The important thing to note here is that the built in authorization model for AAD takes advantage of SCP and ROLE claims, which appear in the token and can help your API understand what permissions it has been granted by the user.
However, we want to also allow you, in this situation, to use your own authorization layer. For example, you could simply white-list the App ID of the client application to allow it to make S2S calls to your API, without the presence of any ROLE claims in the token. The token issuance behavior here enables this scenario.
Related
I am reading documents for Microsoft Identity Platform to implement api and protecting it by using Microsoft Identity platform and I do understand some what OAuth code Grant flow and Client Credential flow (for daemon apps).
Now when I am reading the documents it is keep mentioning authorization on 'behalf of user' and and 'behalf of itself'. So my question is "on behalf of user" is same as Code Grant flow?. Similarly if client credential flow is "on behalf of itself'.
If not then what is the difference between 'On behalf of user' vs Code grant flow.
Really want to understand as it keeping me in confusion.
Thanks
Azure AD supports the following OAuth flows/grants:
Implicit
Authorization code (with/without PKCE)
On-behalf-of
Client credentials
Device code
Resource owner password credentials
Refresh token
Link to docs: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols
In most of these, the application will get an access token that allows it to perform requests on behalf of the signed in user.
The access token contains both information of the app that requested token but also the signed in user's information.
This allows the target API to check both the application's access (scopes aka delegated permissions) and the user's access (roles/other form of access control).
The "on-behalf-of" flow might be a bit confusing here, but it has a specific purpose: exchange an access token obtained with one of the other flows (except client credentials) for a new access token.
It is used in scenarios where a client app uses e.g. authorization code flow to call API A, and API A wants to then call API B on behalf of that same user.
Client credentials flow is the only different one; when using it an application only provides its own credentials and a user is not involved.
Thus the access token only contains application information, and the application will perform requests as itself.
The target API will usually only check the roles in the token (application permissions, app roles with allowed member type application), though it can also check the id of the calling app if it has a list of allowed applications stored somewhere.
Can I define custom scope(s) and have them returned when using the client credential flow in Azure AD?
In my experiment, I configured 2 Azure AD applications, one for a Web API and one for a client (Web API Client A). I added a scope to the Web API but when requesting the access token via the client credential flow, the scope wasn’t returned. 🤔
Also, it only allowed me to request an access token when using .default for a scope, i.e. api://web-api-client-credential-flow/.default.
I ran across this Azure Feedback item: V2.0 Client Credentials Implement Scopes so it appears scopes aren't supported in Azure AD under the client credential flow?
What’s the point in giving my Web API Client A application permissions for that scope if they are not returned? How could the Web API know if the daemon application has that scope to perform the necessary action?
It would seem I would have to use application permissions?
Yes, you have to use application permissions.
Scopes aka delegated permissions only apply when a user is involved in the login process.
They allow you to act on behalf of a user.
Application permissions are sort of roles given to the application itself.
They only apply when doing client credentials authentication, where no user is involved.
You can define application permissions on the app via the Manifest in the app registration.
These can then be assigned to the client application.
When getting the token, you must use .default because you cannot change your app permissions dynamically.
You always get what has been granted already.
In the token the permissions will be in a roles claim.
Can I define custom scope(s) and have them returned when using the client credential flow in Azure AD?
No, but you can define application permission(s) via the manifest (definitely not as nice as the UI for delegated scopes) and have them returned via the client credential flow:
Then you can provide the client app permission:
Now when requesting a token with a scope of api://web-api-client-credential-flow/.default the "scopes" are returned in the roles claim. Sample JWT
Yes, you need to use api://web-api-client-credential-flow/.default for client credential flow.
And the application permissions will be returned in roles instead of scopes.
Our apis are being consumed by 3rd party deamon applications as well as client applications. For third party deamon application we can expose the api via the client credential oauth flow and for the client application(S) we use the implicit grant outh flow.
The challenge we are facing is that in case of the implicit grant flow the user details are fetched from the ACCESS TOKEN. But when the same api is used for the client credential flow the user details can not be fetched from the ACCESS token as it has only application specific details.
What is the the best api design approach to handle the above challenge ?
Do I need two set of api(s) one for integrating with client application and one for integrating with server application ?
Will the usage of any alternative oauth flow help ?
Refer to Authentication scenarios for Azure AD documentation, as you stated correctly user interaction is not possible with a daemon application, which requires the application to have its own identity. This type of application requests an access token by using its application identity and presenting its Application ID, credential (password or certificate), and application ID URI to Azure AD. After successful authentication, the daemon receives an access token from Azure AD, which is then used to call the web API.
The quintessential OAuth2 authorization code grant is the authorization grant that uses two separate endpoints. The authorization endpoint is used for the user interaction phase, which results in an authorization code. The token endpoint is then used by the client for exchanging the code for an access token, and often a refresh token as well. Web applications are required to present their own application credentials to the token endpoint, so that the authorization server can authenticate the client.
Hence, the recommended way is two have two version of api implemented with two different type of authentication based on your scenario.
Reference -
Daemon or server application to web API
Understanding the OAuth2 implicit grant flow in Azure Active Directory (AD)
Our team is starting to build out a SMART on FHIR (SoF) application. SoF uses OAuth2 access_tokens to represent authorizations. Our app is using the code grant to get a token (https://oauth2.thephpleague.com/authorization-server/auth-code-grant/).
I'm pretty new to OAuth2 (used to SAML) and have been reading up on the standard. I think we may be conflating what the access_token is intended to represent.
Is the intent in OAuth2 that the access_token represents the permissions the resource owner (end user) has granted to the client (web application) to perform on their behalf?
Or is the intent to rely that the resource owner (end user) is allowed to preform certain operations?
For example say the auth token request has a scope called 'contacts-update'. If we get an access_token back with this scope, does that mean the user has allowed the application to attempt to update contacts (on their behalf) or does it mean that the user has the underlying requirements (they are in the update contacts role) to be able to update contacts?
As you wrote, the OAuth2 access token represents a permission delegation from a resource owner to a client (application), so the client can perform operations on behalf of the resource owner. That's also why there is a consent page - the user agrees on giving the application permissions (scopes) it requested.
Sometimes, people want to use OAuth2 as a central authentication server and a permission configuration for their applications. They want each application to see all permissions the user has configured for it. Then it doesn't make sense for application to ask for specific scopes, but to configure the OAuth2 server to return all relevant for that application (identified by a client_id). But I don't think this is the intended way of usage and the OAuth2 specification doesn't cover this scenario.
OAuth2 can also be used for authentication only, if it supports OpenID Connect extension. Then applications can ask for ID tokens. ID token proves identity of a user and the permissions are handled in each application separately.
I'm building a native Mobile App that connects to a REST API.
I'm looking at this demo oAuth App to use as a guide for my Authentication/Authorisation layer.
When the user comes to the App for the first time I want to provide them with a username and password box.
After they hit submit I want to the App to be supplied with an access token, and a list of permissions (scopes?) that the user is permitted to perform.
I've read lots about the oAuth2 specification but am confused as to which flow to use.
I can't use the Resource Owner Password Credentials Grant because I can't trust the Native App with the Client Secret.
I don't want to use the Implicit Grant, as I don't want to present the user with a "Do you authorise this App?" web window.
I've looked into the JWT Bearer flow, and think it might be what I need as it doesn't require the Client ID/Secret. However I can't find any examples where this flow returns permissions (scopes?) that the user can perform.
Edit #1:
I am confused as to the use of Scope. The specification says-
The authorization server MAY fully or partially ignore the scope
requested by the client, based on the authorization server policy or
the resource owner's instructions. If the issued access token scope
is different from the one requested by the client, the authorization
server MUST include the "scope" response parameter to inform the
client of the actual scope granted.
If the client omits the scope parameter when requesting
authorization, the authorization server MUST either process the
request using a pre-defined default value or fail the request
indicating an invalid scope. The authorization server SHOULD
document its scope requirements and default value (if defined).
From that can my Client request a list of ALL Scopes, and then the Authorization Server give a Response with the ones the User actually has?
Thanks for your help, Tom.
You list two assumptions about OAuth 2.0 flows that are not true:
the Resource Owner Password Credentials Grant can be used with a public client i.e. a native app that doesn't have a client secret
usage of the Implicit Grant does does not imply that it requires explicit consent; that is to the discretion of the Authorization Server implementation; in an enterprise setting or a setting where the same party controls the client and the Authorization Server, that may be omitted
But since the Implicit grant comes with security considerations, for native apps it is typically better to use the Authorization Code grant.
Scopes are a way for the Client to request certain permissions. The Resource Owner can grant the Client permissions that relate to these scopes (explicitly or implicitly). Since the Client will change its behaviour based on what permissions it gets, it is assumed that there's some shared understanding between Client, Resource Server and Authorization Server about what Scopes related to. There's no predefined semantics in the OAuth 2.0 specification, it is up to the implementation.