When building an OAuth 2 server, is there anything wrong with associating scopes to users? Essentially allowing scopes to act as your applications roles?
I've looked at the RFC but can't seem to find any guidance on this.
The use case for a flow would be something like this:
A client requests an access token.
|
↓
On the server side: it checks to see if the user
is able to receive the requested scope(s).
⁄ \
↙ ↘
Check Passes: Check Fails:
| |
↓ ↓
Server issues token. Server denies request for token.
Some more visual context, this is a SQL data representation:
The definition of scopes is out of scope (!) for the OAuth 2.0 spec itself. Typically scopes represent application permissions or roles indeed bases on shared understanding between the Authorization Server, the Resource Server and possibly the client. What you describe is a common use case for most OAuth 2.0 grants, such as the Authorization Code grant where an application (client) will act on behalf of a user, inheriting a (optionally limited) set of permissions that the user grants to the application, all within the powers that the user itself has.
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
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.
I am trying to understand OAuth2 and its grand types. I just want to know what is the propper grant type flow for authorize a browserless application (a job for example) with a REST API.
authorization_code and implicit flow require user interaction (writing the username and password in the browser), hence both are not suitable for browserless authorization.
client_credentials could work, but there is no user in the authorization process, so what happend if the REST API needs to know the user to check for permission/roles/scopes? Maybe creating a client for each user could work, but sound like a bad thing.
passwordgrant type will be deprecated in the OAuth2.1 specification, so this is not an option.
You may thing that OAuth2 is not the framework to use in this case, because you don't need authorization delegation, but what about if you have both (it is so common), a single page application where you could delegate authorization and also a REST API. What is the propper way to authorize a REST API using Oauth2?
Given that this is a background job, Client Credentials Grant is the best OAuth 2.0 related approach. And, it does not use any end user credential (End users and clients are two different entities with respect to OAuth 2.0). Hence you simply need a credential for the given client application.
Other approach is to enable API tokens. But this will require a manual step where you will insert the token to the background job. Again, this is independent from any end users.
p.s - Read about roles (i.e - client vs end-user/resource owner) - OAuth 2.0 roles
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.
My needs:
Let's consider 2 end-users of the same domain.
User UA is the resource owner of resource RA.
User UA wants to delegate access of resource RA to end-user UB.
My main OAuth 2.0 interest comes from total token control (revocation at any time, etc.).
OAuth 2.0 Framework allows a client to act on the behalf of a resource owner with it's explicit permissions.
Oauth 2.0 defines resource owner and client roles (see the roles section) where:
Resource owner can be an end-user (that can grant access to a protected resource).
Client is an application making protected resource requests on behalf of the resource owner.
In the spec, the client is always considered as an application (with no particular implementation characteristics).
I would like to know if it is ok to implement OAuth 2.0 with an end-user as the client role or am I abusing OAuth completely?
My intuition is that OAuth 2.0 is only designed for third party application (with interoperability) and not for 2 end-users of the same domain. Am I right? In the other hand all the token mechanism really fits my needs.
PS: This expired OAuth specification (2010) talks about delegating authorization by a Resource Owner to another user via a Client using the OAuth protocol. But it's not that relevant.
I would like to know if it is ok to implement OAuth 2.0 with an
end-user as the client role or am I abusing OAuth completely?
Well, it is only an opinion of mine, but if, say, a Buffer can represent me posting my contents to Facebook using OAuth, why my friend Jack (a human, not robot) can't?
Of course, you must think it all over, especially in terms of security. But the abstract scheme looks fine by me.