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.
Related
I am working on the ASP.NET MVC 5 web application. It has only one layer which contains views as well as business logic/operations. Business logic is logically separated from UI but it is not behind a separate web service/API layer.
Now when I use OIDC and OAuth2.0 for my application, there is no separate Resource Server, so to say. Because Client itself has all the Resources I want to have access to.
I am using Authorization Code Flow for authentication & authorization.
Questions:
Does access token have any role in this case? If yes, what?
How am I going to practically use the access token? Since the client itself is the resource server, there is nothing to which I need to send access token to.
I guess you get an ID token which contains all the information you need for authentication of a user. If not, you can use the access token to get the user info. If this is all the information you need, then the access token is not needed anymore. This happens, because OAuth2 is a permission delegation protocol, not an authentication protocol in a first place.
When you have the user info, you can implement between the browser and your ASP.NET backend in any way. You can take a look at the OAuth 2.0 for Browser-Based Apps RFC.
In this case you should use Client Credential flow instead of Authorization Code flow.
In Client Credential flow, your application would send your client id & client secret to Authorization Endpoint directly and asking for access token. Authorization Code is not needed in Client Credential flow. Details as below
An authorization code flow typically need your client redirect
resource owner to authorization endpoint and get a authorization
code from authorization endpoint, client than uses this code to get
access token, at the end of the day client uses access token to
access protected resource.
In Client Crendential flow. your client app is actually the owner of
your resource. So no need to asking for a authorization code. direct
uses its own client credential to get access token from
authorization endpoint and use that access token to access protected
resource(Resource server)
From my understanding: -
The scopes that an oauth client can obtain are registered against the client on the Authorization Server .
The grant types that a client can use are registered against the client on the Authorization Server .
Resources are configured to allow requests containing access tokens that are associated with certain scopes.
Is there a mechanism in vanilla OAuth where the grant type in addition to the scopes are used when restricting an endpoint?
For example, given Client A with scopes=organizations, images and grant types=client credentials, auth code:
(at token creation)
For Client A to obtain an access token for ‘organizations’ scope, only client credentials grant type can be used.
For Client A to obtain an access token for ‘images’ scope, only auth code grant type can be used.
Or (when the resource endpoint it calls)
When the /organisation endpoint is called with an access token containing the expected ‘organization’ scope, only allow the request if the client credentials grant type was used to obtain the access token (fail if any other grant type was used).
When the /images endpoint is called with an access token for containing the expected ‘images’ scope, only allow the request if the auth code grant type was used to obtain the access token (fail if any other grant type was used).
As far as I know scopes are only limited by what is registered for a client.
The only way I can think of achieving the above would be to have two client registrations (e.g. b, c) for the same actual client (A) and configure client ‘b’ for client credentials grant type and organizations scope and client ‘c’ for auth code grant type and images scope.
Update
One option would be along OIDC lines to add a roles scope which would mean that the roles claims would be added to the access token. The access token could then be inspected to see whether the role is a third party (client credentials grant) or user (auth code grant).
I would still be interested to know if there is anything specifically built into oauth to restrict by grant type.
Tokens don't generally record grant information, and really the requirement is to be able to control access per application and based on the caller's rights.
I would always configure different OAuth Clients for different grant types - since these are different logical clients and can never share a session.
A few possible options:
OPTION 1. Use multiple APIs each with a different audience and configure different audiences for different OAuth Clients if that is supported by your Authorization Server
OPTION 2. An API endpoint can potentially check the client ID in access tokens against a list of allowed client IDs - though this is not a good long term option
OPTION 3. Use OAuth just to identify the caller and then look up rights for the caller that are stored and managed in your application data. This is almost always the best long term option.
OAuth only provides high level mechanisms for authorization and when you get into deeper domain specific authorization (eg what a role means or rules such as checking sufficient funds) it will not help you.
I like your idea of using roles, and from experience I would manage them like this:
Do high level OAuth authorization first via scopes etc
Identify the caller from the token's claims
Look up the caller's role(s) in your application data
Enforce the role's authorization rules in your API logic
I have:
Spring boot client application with some public endpoints and private endpoints which require #PreAuthorize("#oauth2.hasScope('resource.read')") for example
I have a external authorization server: Cloudfoundry UAA
I have a external OIDC provider linked to UAA I can use that to authenticate a person, I receive a Person_ID from the ID_Token from that external OIDC provider
Now I need to change UAA core code to implement my logic of using that Person_ID and searching for equivalent user from LDAP which shares the same Person_ID and then I will need to add it's usergroups to the token for the client. (I have done it currently in the /userinfo endpoint)
So I have done this logic in the /userinfo endpoint, when client receives a access token (From client, redirected to UAA, from UAA to OIDC for AUTH, then back again for the token and then this token is sent to client, now client can take the token and ask for the /userinfo which will then have it's user roles)
Is this bad logic? Should I add the LDAP implementation(step4) inside the access token already somehow?
Really, as is often the case with design questions, it depends.
The key to remember is that OIDC and its associated id_token are for authentication. It's common for the /userinfo response to state claims about who the user is. Part of the user's identity might be their role.
OAuth and its associated access_token, on the other hand, are for authorization. It's common for the access token to state claims about what the client is authorized to do. What a client might be able to do may be different than the user's role.
Think about what decisions this client will need to make. It may be able to make choices like which of its pages it can show, based on the roles that it inferred from the /userinfo response.
Think about what this client will communicate with. Maybe it will communicate with a resource server. If the client passes the access_token obtained during login, then that token should indicate what the client is authorized to do.
I am asking a question conceptually here as I am trying to understand the relationship between scopes and user roles in an OAuth2 based system.
As I am implementing an API, I want to restrict access to specific resources by using scopes on the resources. I understand the use of access tokens to request resources, and I believe my understanding to be correct in that you specify your scope(s) when requesting the access token.
What I am not entirely sure of is how restriction of scopes would work based on specific roles that an authenticated user is in. Let's assume Bob is an admin and Sue is a regular user. We have some resources protected by an is_admin scope. What stops Sue from requesting (and receiving) is_admin scope in her access token?
I am thinking that what should happen is the following:
Bob authenticates.
Bob's roles are looked up after his authentication is complete. His "admin" role has the "is_admin" scope attached.
Bob asks for an access token with all the scopes collected from his various roles
Bob is automatically given those scopes for his access token
Is it up to my calling app to enforce only sending asking for the scope Bobs needs? Or is there something I am missing with regards to scopes?
Can someone please enlighten me with some simple examples?
In OAuth2, there are the following roles:
Resource owner - usually some person
Auth provider - the OAuth2 server
Resource server - an API that requires an access token and validates its scopes
Client application - application requesting an access token with some scopes.
To understand OAuth2, it's necessary to think about it as a protocol for access rights delegation from a Resource owner to a Client application. So the main use case is: the Client application wants to access the Resource server. In order to do that, the Client application needs an access token issued by the Auth provider and authorized by the Resource owner (which gets authenticated by the Auth provider).
In your description, the Client application is missing. Let's assume it's a frontend application for your API. It needs an access token with scopes admin-user-scope or regular-user-scope. So it redirect a user (Resource owner) to the Auth provider, requesting both scopes.
The Auth provider authenticates the user and asks him/her for a consent on granting some of the requested scopes to the Client application. The Auth provider may remove some scopes - for example the admin-user-scope for non-admins. The Auth provider may give the user a possibility to remove some scopes too.
The Client application receives an access token (or a grant) with scopes in a redirect URI. If the granted scopes differ from the requested scopes, the Auth provider sends a list of granted scopes (the scope URL parameter) along with the access token, so the Client application knows what actions it can perform with the access token.
Then the client application may access the Resource server and the Resource server makes sure that the provided access token contains required scopes. The Resource server uses the OAuth2 introspection endpoint to validate the token and to get a list of its scopes.
I am using the OAuth2.0 for authentication and authorization with the WSO2IS. I have multiple APIs on the ESB. There, the user may grant access to API1 and API2, but not to API3.
Is it possible to define custom scopes to limit the client from accessing all APIs?
If it is not possible, how do I protect the APIs from unauthorized access?
Side note: currently, I may only limit the access by defining different applications. However, this isn't suitable, because I must then manage multiple clientIDs and clientSecrets on the client side.
Yes.. you can define for that... by default, Identity Server does not validate any scope parameter before granting an access token. For that, you need to implement a new OAuth callback handler class according to your resource server. I guess this blog post explain it. However as i know, WSO2 Identity Server not provides access token based on the scope.. Access tokens are issued per client and resource owner. Not per client, resource owner and scope. This has been already discussed on wso2 public mailing list and it would be fixed for next release.