In section 5.4 of the OIDC spec (https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims) it says “The scopes associated with Access Tokens determine what resources will be available when they are used to access OAuth 2.0 protected endpoints.”
As I read this, it seems straightforward, if you have any permissions which an API should respect, the you put them within the “scopes” claim of an access token.
However, both Auth0 and Okta put a users permissions within a custom claim. In Auth0s case, it puts a users permissions within a “permissions” claim and in Oktas case, they put them within a “groups” claim of the access token.
Because both of these identity providers put the permissions as a custom claim, it makes me think I am reading the spec wrong. Does anyone have thoughts or can clear up when to put permissions in a custom claim vs putting them in the scopes claim?
Scopes tend to be a high level permission such as 'read / write' or which API(s) the token can be used against. Claims are what your API needs to identify + authorize requests. Not all claims are included in access tokens. My write up here may help you to understand your choices:: https://authguidance.com/2017/10/03/api-tokens-claims
The difference here is the scopes for the token vs the permissions for the user. Some auth0 users will add users permissions in a custom claim to do things like gate content. The scopes in the token are explicitly describing what the token has access to.
This doc shows an example of the access token with scopes:
https://auth0.com/docs/api-auth/why-use-access-tokens-to-secure-apis#compare-the-tokens
Here is an example of adding permissions to a token via a custom claim (id token in this instance):
https://community.auth0.com/t/how-do-i-add-user-permissions-to-id-token/28611
Related
I am building an app which authenticates via microsoft and needs various that predominantly uses Delegated permissions. I use the v2 auth endpoints to do incremental authentication, only asking for additional scopes when the user needs them.
This has worked well for the many delegated permissions I have so far. In many cases I need admin approval for these permissions, but I have a flow for that which works well.
One of the scopes I have used as a delegated permission is "User.Read.All", I now need the same scope on the application permission level. But I am struggling to work out if there is a way to do incremental authentication for application permissions. The docs say to use the generic endpoint where you don't specify scopes, but this then asks for all the scopes I have on my application registration rather than just passing in the scopes as a param.
It has nothing do with the endpoint and the scopes you specified. Since you use Delegated permissions in your original job, so I consider you use auth code flow or username/passord flow. If we use auth code flow or username/password flow, we can't get application permission when we do authentication although you have assign the application permissions to your registered app. If you want to get application permission when do authentication, you need to use client credential flow instead.
It is not possible to do this unfortunately the consent flow allows either a dynamic set of delegated scopes to be submitted or /.default which acts like the v1 endpoints and requests all scopes for that client. See these docs
When requesting scopes for both channels:read and identity.basic I get the following error:
Invalid permissions requested
Cannot request both identity scopes and other scopes at the same time
What's the solution for this? I'm interested in identifying if a user is an administrator and listing his channels. I'm requesting the identity.basic scope above as it's a prerequisite for the users:read scope. Do I really need to get the user to click "Authorize" twice for such a thing?
No. You do not to authorize twice. If you need additional scopes - because you want to access the API methods - you need to use the Add to Slack OAuth flow instead. That one will give you access to all scopes.
The Sign-in-with Slack OAuth flow is meant for quick user authentications only and does therefore not include any scopes that would require the user to confirm them (like users.read). So you can only user identity.* scopes for this flow as clearly stated in the documentation under Valid parameters / scope.
I use WSO2IS as an OIDC provider for authentication and authorization. Using Authentication Code grant, I got the access-token. I need to authorize the users to access specific services based on their roles.
I tried to use XACML to solve this, but I found that I need to pass base64 encoding of username:password in the header of REST API XACML request. Instead is there any way I can authorize the user to access services based on their roles, using access-token ?
This part of authorization happens in the resource server. I thought I could use the introspection endpoint to authorize the user based on the access token using scopes. But I don't understand how scopes can be used to provide access control to the users ?
To get an access token with all scopes available to a user, the OAuth2 client must request all scopes it cares about and the token will contain only those that the user has access to. See this question.
Yes, it's cumbersome, but OAuth2 is primarily an authorization delegation protocol - it allows users to delegate some of their rights (scopes) to a client.
Alternatively, if you could decide permissions based on roles, you could probably get a list of user roles from an ID token.
I understand the OAuth 2.0 spec. allows third-party applications to grant limited access to the application, either on behalf of a resource owner or by allowing the third-party application to obtain access on its own behalf.
I have a scenario, where I have an application and I need the user to get authenticated with some IAM provider. The roles and privileges are configured in the authorization server for each user. I can query the introspection point of the authorization server and based on the scope details, my application can decide the access to any resource for the user.
In this case, the user is not the resource owner. The types of resources the user can access is decided by my application, instead of the user allowing/denying the application to access resources.
Since the user is not the resource owner, can OAuth/OpenId Connect be used in this scenario ? Is it possible with WSO2 IAM?
I tried the playground sample which is available in WSO2. Once the user logs in, there is a window which asks "playground requests access to your profile information" and requesting the user to allow/deny. Can this be avoided, since in my case the user is not allowed to make any decisions ?
If not, what are the other options to authorize/limit access to resources which is decided by the authorization server/resource server, instead of user granting access ?
Thanks,
Albie Morken
In this case, the user is not the resource owner. The types of resources the user can access is decided by my application, instead of the user allowing/denying the application to access resources.
In your scenario, you are relying on tokens issued by authorisation server to access a protected resource. The protected resource is your application. And this application must have internal mechanisms to verify the tokens it receives to grant access.
Short answer to your question is - YES
You can use openID connect for this scenario. And you have two options to adopt,
1. Use access tokens with introspection end point
You can use access tokens to grant access to your application. The client should send the access token as a bearer token as described in RFC6750. When the application end point receives a request, this access token can be validated against introspection endpoint RFC7662
2. Use ID token
ID tokens too can be used as bearer tokens.ID token is a JWT (RFC7519) and is self contained. It contains validation mechanisms as described by OpenID connect spec which are self sufficient to allow grant. And also to you can check claims it contains to authorise the end user. More can be found from this link.
I tried the playground sample which is available in WSO2. Once the user logs in, there is a window which asks "playground requests access to your profile information" and requesting the user to allow/deny. Can this be avoided, since in my case the user is not allowed to make any decisions ?
Consent page can be disabled. According to spec. it can be done by configuring identity.xml as follow,
<SkipUserConsent>true</SkipUserConsent>
It is described in their documentation too.
Hope this helped.
p.s - WSO2IS contains inbuilt XACML engine. XACML is the standard for access control. You can fine more information from this link.
Assume we have an OAuth2 implementation that supports "read" and "write" scope.
I retrieve an access token "f482c829" with "read" scope. If I then change my mind and now want read+write permission and authorize again with "read" and "write" scope do you:
Update scopes for existing access token and return same token "f482c829"?
If using same token, require that the access token is reclaimed if using response_type=code before updating scopes? (I think yes)
Update scopes for existing access token and return a refreshed token "zf382nL"?
Create an entirely new token leaving "f482c829" and its scopes intact?
If you create a new token every time per scope, you end up having to store multiple access tokens per authorization and different permissions everywhere. I've been hesitant to implement it that way.
The OAuth2 spec (as of draft-12) unfortunately does not address any of this.
In facebook's case, resource server is basically same with authorization server.
So they do "use existing token" way.
And it enable to allow users to disable each scopes on facebook.com site.
About refresh token, you don't need to establish new refresh token. (Of course you can do it though.)
Existing refresh token will also be connected with all scopes.
In Google's case (maybe Yahoo! too), resource server is totally different from authorization server.
Many resource server (Docs, Buzz etc) accept access tokens established single authorization server.
In this case, "establish new token" way seems better.
In Twitter's case (maybe your case too), both seems OK.
Plus, in any way, when user revoked client access you need to revoke all tokens for the client.
User is not revoking "token" but "client".
Since developer should pre-register redirect_uri, using same client credentials both on website and on mobile all seems tricky.
So I recommend asking developers to use different client credentials in that case.
Say one client (mobile) of an application needs read-only access and another client (website) needs to write as well. This would require client to be able to decide the scope of token request and hence provider to store multiple tokens with different scopes.
However, it is up to you if you want to extend the scope of an existing token. This means you can keep one scope per application. This can also make easy to revoke access of an application by a user.