In most OAuth2 typical use cases, the scope is used by resource owner password grant type, or authorization code flow, where a user login is required.
It seems that scope is mainly used to control access of users' resource. For example, to authorize a 3rd party client to access the resource owner (user) resource at another server.
In some cases, user is not present. For example, a company wants to provide a API for another company only. Client credential is being used. Most API gateway products have subscriber management option to control which client ID can access which APIs. In that case, is it still meaningful to use OAuth scopes to manage access to APIs? Why?
Besides, I cannot find any examples using scopes along with client-credential grant type. Is it rare use case?
The Client Credentials grant type is used to access protected resources that both sides own/control/trust.
Scopes are supported by this grant type. They are typically not used because the trust is already there and limiting that trust via scopes is not required.
In other words, the reason that scopes are not used is that if the trust is not there, other grant types are more appropriate.
Related
I have a RESTful API that is consumed by a browser frontend and multiple machine-to-machine clients. So I'm issuing tokens with Keycloak 18 through Standard Flow (Authorization code) and Service Account Flow (Client credentials).
The operations on the API's resources are protected by scopes like read:resourceA, update:resourceA, read:resourceB, etc.
When I assign a Realm Role to a Client Scope, and if I map a user to the same Realm Role, the tokens issued through the Authorization Code Flow (browser frontend) contain the scope.
Also, when I create a Machine-to-Machine client and I add to Client Scope directly to the Client, the tokens for the M2M client also contain the scope.
So far so good. But as soon as I try to do both at the same time, I no longer have the scope in tokens issued by the M2M-client.
It seems that adding a Client Scope to a Role makes it impossible to use that scope otherwise.
The obvious, but bad solution would be to create a second set of scopes for this kind of client. Is there any other solution I'm not aware of?
I'm migrating from Auth0.com to Keycloak, and that's currently the only point blocking me from finishing this migration.
Thanks,
Pascal
In a standards based approach, scopes are composed of claims. Scopes are fixed at design time, whereas claims have runtime values. So at runtime a particular client and user may result in these values:
- myscope
- roles: [user, admin]
- subscription-level: gold
An example is the built-in profile scope, which includes name and email claims, and might look like this at runtime:
- profile
- name: John Doe
- email: john#doe.io
It is recommended to avoid scope explosion, as you suggest. In Keycloak I would keep scopes the same for all clients, so that nothing changes in the client interface.
A realm role is a type of claim, though a Keycloak specific concept I think. Perhaps you can represent it differently, or configure a realm role for the M2M client also?
It turns out that I missed the concept of Service Account Roles. For all those running into the same troubles:
How to add a new Role to an Authorization code flow client
Create client with Default Flow enabled
Create client role
In Client Scope Settings, add the new client role to the scope
In Client Settings, add the scope(s) to the list of default scopes
Add the new client role to the user
How to add a new M2M client
Create the new client
Create a new client role in the Client settings
In the Client settings, in the tab Service Account Roles, assign the new Client Role
In the Client scope settings, assign the new client role
In Client Settings, add the scope(s) to the list of default scopes
I'm aware of how OAuth2 and OIDC can use custom scopes and token introspection to secure an URL like this:
/users/me/documents
I can give this URL the documents:view scope and when receiving the token from the authenticated user, I can ask the authorization server if this user has the correct permissions. Then I can use the preferred_username claim or similar to see who /me actually is.
But what if I have a resource which is accessible by multiple users? Let's say a user has documents but they can be viewed by his direct manager. To retrieve the employee's documents as a manager, I'd need to have an url like this:
/users/${userId}/documents
How could I enforce it in a way that only the resource owner and direct manager can view this resource? I don't want everyone to access everyone's documents by knowing the userId. I could grant access as a whole to all users with the manager role, but that's not specific enough.
I'm aware there's the UMA extension where users can grant access to resources on his behalf to other users, but it's not the user who grants permission. It's the system who states in this case that managers can access their employees documents.
Would it make sense to write a custom policy which extracts the ${userId} and performs the check? Or should this not be done by the authorization server at all and be done by the resource server instead? Perhaps a different approach to reach the same goal?
Finer grained authorization like this is done with claims rather than scopes. There may be business rules around which docs a user can see, eg:
A user can access their own docs
An admin has view access to all docs
A manager can view docs for people they manage
In an access token this might be represented by these claims:
userId
role
Claims are often domain specific like this and the preferred option is to add them to tokens during token issuance. At Curity we have some good resources on this topic:
Claims Best Practices
CLAIMS AND AUTHORIZATION
The Authorization Server issues access tokens and then APIs (resource servers) verify the access token and use the token data to apply authorization rules (which are often domain specific) on every single request.
Claims are often used when dynamic behaviour is needed - they are runtime values that derive from the user identity, whereas scopes are fixed design time values. In your example an API might also need to vary SQL to retrieve documents based on the user identity.
There are more complex variations on this theme, such as an API calling a system such as Open Policy Agent, so that documents returned are determined by rules configured by a security administrator. That policy would still involve using claims from the access token though.
EXAMPLE CODE
If it helps, here is some sample code of mine that show the type of approach when enforcing domain specific authorization rules. Typically you need to filter collections and check access to individual items.
Currently building up a microservice for handling auth-related stuff using OIDC.
Now, we think about access control and how to be as future-proof as possible. This auth server is only used for first-party applications (3x SPA, 2x native mobile App). On mobile, we use the authorization_code grant. Each resource server validates the supplied token (access token as JWT) itself. But what happens when (in future), we add a service which needs its own scope to check (e.g. notifications:read)? As mobile app users are not used to logging in and out everytime (when we would update the requested scopes via an app update -> bad solution) is there any sweet solution to manage this scenario?
Per specification, it's possible to change the required scopes when refreshing a token but this is limited to require less scopes than originally requested and not more so that's not an option.
For example, Facebook is providing only four scopes for Instagram e.g. instagram_basic or instagram_content_publish. Zalando for example includes only a scope NORMAL_USER in their tokens whereas Wolt includes the users roles as a claim.
I think there is some confusion as this scenario is not covered directly by OAuth2 or OIDC. What are your thoughts about this?
There is one standard for doing OAuth 2.0 Incremental Authorization, but your challenge is to find a token provider that supports it or similar standards.
In a micro service architecture, the question is if you should use the access token from the authorization code flow everywhere, or if for service-to-service communication, you should use client credentials flow instead.
See also https://www.gmass.co/blog/oauth-incremental-authorization-is-useless/
It seems like you could use Token Exchange for that.
For example it could work like that - whenever your resource server gets a token without the notifications:read scope, issued before date x (so before you were issuing that scope) it performs an exchange with the authorization server and (if the server decides that it can perform the exchange) it gets a new access token that contains that scope. If the token was issued after date x you can safely assume that the token was not granted this scope.
Another solution would be to use claims for authorization decisions instead of scopes. The authorization server can issue e.g. a claim notifications_read: true, or something like that. Whenever you refresh tokens you can issue more claims in the new access token, the spec does not prevent that. Then your resource servers should check claims in the access token, they can ignore scopes. The resource server would just check whether the token contains the notifications_read claim with value true, or not. This solution gets a bit more complicated if you require your users to give consent to scopes, but as you said you're using this only for 1st-party, so I assume you're not using consent screens.
You can have a look at this free course - this topic of using claims in authorization is covered in part 4.
OAuth 2.0 protocol provides permissions delegation of a user so that third-party apps can operate on its behalf. A typical way this is done on the OAuth flow is requesting a user consent to either approve or deny access for the app (Okta example). Here is an official spec describing how it works in general concepts.
I'm looking for the standardized approach to perform the same flow but for the user groups (e.g. organizations). GitHub does that in some way for organizations, so it looks like organizations represent just a group of user accounts. Are there any standardized approaches to this problem?
If not maybe there are any recommended ways how its typically done architecturally or can fit into OAuth 2.0/OpenID Connect protocols.
The OAuth 2.0/OpenID Connect protocols do not cover how access control is performed.
You can, within the OAuth 2.0/OpenID Connect protocols, pass OAuth Scopes or use the OIDC user info endpoint data to allow the resource server to make determination for Access Control.
Many of the commercial products within this area allow the use of LDAP as a back-end for authentication and will even convert LDAP Groups to Scopes.
I would assume, but I do not know, that GtHub stores data with a link (like a group) for the on Organization and/or the user. I know GitHub exposes this using OAuth Scopes.
Oh, and the OAuth Spec is at: https://oauth.net/2/
But if you require Authentication of users then you need to be using OpenID Connect which is built on-top of OAuth 2.0.
Remember that "OAuth 2.0 is NOT an Authentication protocol"
-jim
There are limits to what you can show on the consent screen and dynamically calculated data is not usually supported.
You ought to be able to express a high level scope that you can present to the user though.
In terms of authorizing based on a user's organisations the claims caching technique here can be useful:
https://authguidance.com/2017/10/03/api-tokens-claims/
That is:
* Use OAuth for user identification and high level checks
" Then do the real Authorization based on your back end data
I'm making some assumptions here, but I believe the issue arises from trying to authenticate two things at once.
If the organization is what you need, then go ahead and create a flow to authenticate the organization as the principal subject (via a user who has access to it), instead of actually authenticating the user itself.
Once the access token is generated, you do not necessarily need to know which user generated it anymore (or at least, the token itself does not need to know). If your user needs to be able to view and/or revoke access tokens, they should still be able to do that, since they have access to the organization in your app.
I am trying to understand IdentityServer3 and different terms associated with it in order to secure my Web APIs. Can someone explain what is significance of Scope in IdentityServer with some good example.
I found this link but idea is not clear.
Thanks in advance!
Scope
It's safe to say that Scope is kind of a role to access a specific set of resources IMHO. IdentityServer has two scope types, the ScopeType enum is defined and described as 'OpenID Connect scope types.'
Identity Scope : representing identity data (e.g. profile or email)
For example, if you have a profile identity scope, then clients with this scope can get the profile data from an identity provider ( e.g. IdentityServer )
Resource Scope : representing a resource (e.g. a web api)
For example, if clients have a calendar resource scope, then they can call a /get/calendar/months web api and get the resources.
Scope will be included in Claim when a HTTP request with an access token is in flight and will be further validated at the validation stage for the access token.
Of course the client should be added prior to running IdentityServer and proper scopes should be specified in AllowedScopes; a member of the Client class in IdentityServer.
The better resource to know about oAuth2 is IETF, and about OpenID Connect is openid.net.
IdentityServer is an implementation of OAuth2 and OpenID so it's documentation will not cover the basics that related to OAuth2 and OpenID.
To understand first about scopes you should have a clear understanding about clients.
Client: Models an OpenID Connect or OAuth2 clients (not your client application) and it should have a clear flow for example you defined a client which uses implicit flow.
The flow is the way that you should follow in order to get the needed data for example access_token and id_token.
All flows can be used with any cases but there are recommended flows for every case.
For example, up until now, it was recommended that you use implicit flow with native and javascript clients. Though, recently this has been changed to Authorization Code with PKCE. See Identity Server's blog post on this change to IETF/OpenID recommendations
Scopes: Models an OpenID Connect (Identity scopes like email, given_name etc.) or OAuth2 (Resource scopes like your WebApi that you want to protect it's data) scopes.
You can think about scopes as intent of the client, for example: The Client ask you to use your resource owner to grant me access to your openid scopes > given_name, email & prefered_username and your OAuth2 scope > WebApi.
For full understanding:
1- Pluralsight - Building and Securing a RESTful API for Multiple Clients in ASP.NET
2- Pluralsight - OAuth2 and OpenID Connect Strategies for Angular and ASP.NET