If a client allows the following scopes, can it have different client secret for different scopes (e.g. secret1 for the "opened" and "profile" and secret2 for the "api2")?
"AllowedScopes": [ "openid", "profile", "api2" ],
I mean can it limit the client with secret1 to access the opened" and "profile" scope only, but not the "api2" scope and client with secret2 access the "api2" scope only? If not, what is the right way to achieve it?
From what I have read, the client secret is used to authorize access to the token endpoint. Client with secret1 or secret2 can create token of any of the allowed scopes.
If that is the case, what is the use cases for client with more than one secret? Why not have one secret only to access all allowed scopes.
Related
I've read docs and seen this. Struggling to put Cognito + API GW + OAuth2 pieces together. My questions:
Do I correctly understand the flow and use of Resource server scopes: client app asks the Cognito user pool for a JWT token (login/authorization happens). Request for a token contains custom scope A so as the Cognito returned JWT access token. After that client app uses obtained token making a REST API call to a "resource server" (say, to our configured API GW endpoint). API GW endpoint is set to use our Cognito user pool as authorizer + scope is set to be custom scope A. Thus scope here acts like a "role" or "permission": if client has a valid JWT token + this token has a custom scope A inside + API GW endpoint is set to use that scope - then client app is authorized to call API GW endpoint. Effectively it acts like a "resource-based IAM policy" for endpoint but no IAM is involved here.
Do I correctly understand that AWS Cognito Resource server identifier is an arbitrary string? It is not the URI of a factual "resource server" (our API GW). URI format is used purely for uniqueness and there is no place in flow where Cognito Resource server identifier matters or somehow checked/validated? Also it looks like that Resource server identifier does not affect JWT token generation or token contents?
thanks for clarif.
Application scope should not be confused with user permission. Scopes define the access an application has to the user's resources. Therefore resource access is the overlap of the two:
Check that the user has access
Check that the application has scope (access to user acccess)
Example
2 Clients with scopes:
A: E-Commerce (product:create, product:remove, order:create, order:update-status, order:read-status)
B: 3rd-party Order Tracker (order:read-status)
2 Users with permissions:
Customer (order:create:owned, order:read-status:owned)
Admin (product:all, order:all)
Therefore…
Customer PUT /product with client A = DENY due to missing user permission
Admin PUT /product with client B = DENY due to missing scope
…
By requiring a URI, AWS seems to enforce collision resistant identifiers as you point out. It's not a common practice and doesn't really have any real security benefit, nor is it validated by AWS that you control the resource.
I am using WSO2 Identity server and WSO2 API Manager to manage access. I want to ensure role based access control to APIs using oauth2 scopes and authorize end-users to access my APIs based on their roles. For this purpose, I have to expose my APIs on the api manager and create a SPA for users authentication before accessing the APIs. I have many users (developers, publisher, customer, agent,etc)
To do this, I first configured wso2am-3.2.0 with wso2is-km-5.10.0 using the following guide.
https://apim.docs.wso2.com/en/latest/install-and-setup/setup/distributed-deployment/configuring-wso2-identity-server-as-a-key-manager/#step-1-download-prepackaged-wso2-is-as-a-key-manager-wso2-is-km
To perform role based access control to APIs for developers, I created scopes to API and assign scopes to roles. I'm able to generate an access token for each scope but the roles validation is not performed and all my users whatever their roles can access to my APIs and access was not restricted by users roles. When I tested role based access control to APIs with the default integrated key manager of the API manager (https://apim.docs.wso2.com/en/latest/learn/api-security/oauth2/oauth2-scopes/fine-grained-access-control-with-oauth-scopes/), it is working normally but the integration of WSO2 identity server as key manager leads to this behavior.
Did I missed any setup in the WSO2 identity server or API manager for roles validation when accessing to an API with a given scope?
I can get an access token for each scope as follows:
{
"access_token": "x",
"refresh_token": "x",
"scope": "view_item",
"token_type": "Bearer",
"expires_in": 3600
}
We can use below API to generate token based on scopes associated with user role.
https://localhost:9443/oauth2/token
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
Using Ping as OAuth authorization server, when introspect access token issued with client credential grant type, the resulted output does not include "sub" claim. Is there a way to configure Ping to include some functional ID or technical ID in the "sub" claim?
If you have PingFederate 9.0 and up, the Client Credentials grant mapping contract is customizable (see Version History here) for these purposes.
To add a "sub" claim, add the attribute "sub" to your Access Token Manager instance's contract. Then, in your Access Token Mapping (under Grant Mapping in the administrative console) you can add a mapping for the Client Credentials context for your Access Token Manager instance. You will then be able to define the fulfillment logic (as you say to some ID value) there. For more details, see: https://support.pingidentity.com/s/document-item?bundleId=pingfederate-92&topicId=adminGuide%2FaccessTokenMapping.html
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.