I'm using WSO2 IS (5.11.0) as the key manager of APIM 4.0.0). I have published a graphql API which is secured by a scope (say 'test_scope' based on a role named 'test'). I have subscribed to the API with the Default Application and have generated the keys as well. When I generate the access token with the scope ('test_scope') and invoke the secured API I'm getting the valid response even though the required role ('test') is not assigned to the user. Below is the curl command which I'm using.
The API Manager will perform the Role-based validation during the token generation. So, if you are generating the JWT Token with a user that has the respective role assigned, then the API Manager will generate the access token with the requested scopes (that are bound to the role).
I believe that you have generated the JWT token using either Client Credentials or Password grant (not able to find the cURL in the question :)), and the token has been generated with a user who has the respective role assigned. To give more clarification, when using the Client Credentials grant, the API Manager will use the Application Owner as the user to verify the Roles and to provide the scopes. Whereas the Password grant, uses the respective username (that is sent), to verify the roles and scopes.
During the runtime, the Gateway will decode the JWT token and verifies whether the required scopes are available. If yes, the Gateway will proceed with the request, and if not it fails.
So to check the process, you can use another user in the same tenant who hasn't been assigned with the specific role and generate the Token with Password grant and invoke the API (in this scenario, the token will be generated with the default scope and not with the mentioned test_scope).
Hope this clarifies and provides a brief understanding of the Token generation and scope validation process.
Related
I am working on a cloud native microservices based application deployed in AWS. This application should use a OIDC based IdP (preferably AWS Cognito). The authentication and authorization flow are as follows. Once the user logs in using authorization code flow, the IdP generates one ID token and access token. The access token is sent to the backend services for the backend calls. The backend service can fetch the user information through /userinfo endpoint if needed. Additionally, the access token has the required group claim and the scopes to determine if the right access is present.
Now if the backend service needs to call downstream backend internal microservices on behalf of the logged in user, then should I create a
new token with client credentials grant with a reduced scope needed for the service call? or
Should I send the initial access token of the user only?
In the first case the user context is lost in the new access token and if the downstream service requires the user context, then how will the downstream service get the user information?
In the second case the downstream service is not called with the exact specific scope needed for that service and is not security best practice.
However, there is also one more grant call exchange grant (https://www.rfc-editor.org/rfc/rfc8693.html) which supports creating a new access token with the user context from the initial token without relogging in the user (delegation mode in https://www.rfc-editor.org/rfc/rfc8693.html). Is it supported in AWS Cognito? If not, then how can I achieve the same functionality if I use AWS Cognito?
It kind of depends on the level of trust between microservices. By default, if they are part of the same unit, aim for this type of setup:
Orders microservice, requires an orders scope
Shipping microservice, requires a shipping scope
Customer website, uses scopes orders and shipping
You can then flow the user identity securely, if Orders calls Shipping, by forwarding the access token. Meanwhile each API verifies the JWT on every request and checks for the scopes it needs.
Each API should also check for an audience claim has the expected value, representing a set of related APIs, such as api.example.com. I believe currently though, AWS Cognito does not issue an audience claim to access tokens.
If Shipping is a less trusted subdivision of your company, token exchange would be more appropriate. Eg if you have concerns about a Shipping service abusing Orders privileges.
Avoid over-reliance on scopes, or too many of then. Use claims for the main authorization. In Cognito you can look up these values after verifying the JWT but before your API creates its claims principal
Cognito only has quite limited support for more advanced token behaviour, such as issuing custom claims, reference tokens, or token sharing techniques. If you need them, the preferred option is to choose an authorization server that supports the standards.
I have a cognito user pool/app client setup with OAuth flow and standard scopes (email, admin, etc.) and several 3rd party providers (google, azure, etc.). I would like to get the identity data in the request context which mean I would need to use the id token but using the id token gets me an unauthorized response from api gateway while the access token works as expected. I remember reading somewhere that custom scopes doesn't allow for id token auth but I don't have custom scopes setup. Any insight into what's going on here?
From Integrate a REST API with an Amazon Cognito user pool:
With the COGNITO_USER_POOLS authorizer, if the OAuth Scopes option
isn't specified, API Gateway treats the supplied token as an identity
token and verifies the claimed identity against the one from the user
pool. Otherwise, API Gateway treats the supplied token as an access
token and verifies the access scopes that are claimed in the token
against the authorization scopes declared on the method.
OAuth Scopes are only present in access tokens. Based on the fact that access tokens work, you have specified one or more OAuth scopes for your endpoint.
If you have a valid access token, you can use its value to get information about the authenticated user using the USERINFO endpoint.
I am using WSO2 Identity Server-5.10.0 and API Manager-3.2.0.
Have created application in devportal and subscribed the APIs to this application.
In Identity server have enabled Role based scope validator for this service provider.
using below API to generate token:
https://IS_host/oauth2/token
After enabling Role based scope validator unable to generate token with scope=apim:subscribe and giving the error invalid scope.
user is assigned with the role -Internal/Subscriber
We are creating Application in Devportal and subscribing APIs to this Application.
We wanted to list the scopes associated with APIs which are subscribed to Particular application. hence we are calling below API to list scopes based on applicationId
https://AM_HOST/api/am/store/v1/applications/{applicationId}
To invoke this API we need to generate Token with scope: apim:subscribe, But after enabling Role based scope validator we are unable to generate token with apim:subscribe.
if we disable Role based scope validator, user will be able to generate token for all the scopes irrespective of roles associated with user.
The apim:subscribe scope is a reserved scope for API Manager REST APIs. Hence, it is not required to create an Application from the Devportal to generate the Tokens with it. You can perform a DCR operation straight to the API Manager to register a client and generate the Access Tokens with the API-M reserved scopes.
Further, I believe that you have configured the IS as the Key Manager by following IS-Connector approach. The Role Based Scope validator feature requires a set of DBs to be shared among the servers.
Hence, the best way to generate the API-M specific scope tokens would be as following
Perform DCR operation to the API Manager instance (not the IS)
This creates a client in the API Manager using the Resident Key Manager of the API Manager and responds back with the consumer credentials (client ID and secret)
Perform Password grant to generate the token using the received consumer credentials
You can learn more on performing the DCR and subsequent calls in Devportal REST API Docs
Hope this helps you to overcome the reported behavior.
We have created a service provider in wso2 IS.Under 'Role/Permission Configuration' section of that service provider we have added some custom permission.
Is there any way for the 'oauth2/token' call to return the permission associated with that service provider. currently we are passing the scope as 'openid' and getting id_token in response we also want id_token along with permission values.
or is there any way to create scope for each service_provider and get in 'oauth2/token' response?
Note: We are using grant_type='client_credentials' for getting id_token.
Note:- With client credentials grant type we don't have any user authentication, only the client will be validated using client id & secret. Therefore there is no way to get service provider vise permission along with id token. The below solution would be useful when you use a grant type where user authentication exists.
Writing a custom claim handler and handle the logic to assign permission values in that custom claim handler. I have written a sample custom claim handler to retrieve custom permissions along with id token.You could refer https://github.com/nilasini/CustomPermissionClaimHandler and follow the readme instructions.
I need to connect to another web application using webservice. That web application uses OAuth protocol to connect to their api. I am new to OAuth, but I did read the documentation :D .
My question is, to connect my web application with their, what data do I need from them?
I basically need to get all data of resource owners.
I think I need:
1) consumer key and consumer secret key from that web application
company
2) token credential from the resource owner
I need this info right?
Can I save the resource owner token credential to get data in the future without resource owner login?
In their web application, it says I can get the following info from them:
OAuth access tokens and secrets - > are these the token credential of
the resource owner?
OAuth Service key and secret -> what are these?
I need this info right?
Yes. You need the resource owner to authorize your application through the OAuth flow. This is signified by token credentials (this used to be called access token).
Can I save the resource owner token credential to get data in the future without resource owner login?
Yes. Token credentials may have limitations on them in regards to expiration time, type of resources you can access etc. But if token credentials are expired (or invalidated by the resource owner him/herself) - your requests will not be accepted and you will have to ask the resource owner for new authorization.
OAuth access tokens and secrets -> are these the token credentials of the resource owner?
Yes. Until recently token credentials were called access tokens in the specification, information about the name changes can be found here: https://www.rfc-editor.org/rfc/rfc5849#section-1.1
OAuth Service key and secret -> what are these?
These are most likely the consumer key and secret.
I followed this Tutorial and it is simple to understand.
Here is the sequence of flow to get it all working.
Get registered on the API Provider (the web application in your case). This will generate client id and client secret for you.
Exchange client id, client secret, end user id/password (in base64 encoded format in http auth header), scope, grant with the API Provider's auth service and get Authorization Code.
Exchange client id, client secret, authorization code with API Provider's token service and get token.
Use this token with other query parameters to proceed with the API requst.
The sequence above is applicable for grant_type=code. If you are going for any other grant type, #2 is not applicable, and in #3, you provide end userid/password to get token directly.