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.
Related
We are working on switching to Cognito as the 3rd party OAuth 2.0 provider for our backend services.
Our legacy system had its own Spring Authorization Server (deprecated) for generating and verifying access tokens which enabled us to add custom claims to Access Token itself, there was no need to carry around Id Token to extract information about the authorised user.
But Cognito pushes us to use OAuth 2.0 standards naturally, and there is no possibility to add custom claims to Access Tokens. Id Tokens are used for extracting custom claims and user information throughout an authorised session.
This brings us to a situation where we need to have Id tokens in the backend service sessions for the endpoints that needs some user info in order to process requests. But to fetch the Id token from the Cognito provided /userInfo endpoint, Access Tokens need to have openid scope, but to have the openid scope in the Access token, we need to use Cognito Hosted UI which is not applicable for the mobile app and our legacy Web app.
So either we need to use Identity Token as the Bearer token(not advised by standards), or we need to expect ID token with a custom HTTP header along with the Access token. Is there a huge security risk if ID tokens are used also for enabling access to REST API's ?
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.
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.
I have an API Gateway/lambda REST API that is being accessed from a react web app. I need to add authentication using google as an identity provider. The app should also keep the user signed in.
I understand when the user first grants access to the (react) client app, it should send the ID token to my backend, which should then verify the token.
Since my architecture is serverless, I assume the verifying should be done in the API Gateway authorizer function, which then grants access to the API on successful verification of the token.
My question is, how do I then create a persistent session? Should I be saving anything to my database about the user? Does the token need to be verified on every API call?
Should the authorizer be checking if the user is already registered or if it's a new user?
It would be easiest to use AWS Cognito for this. Configure a user pool as an authorizer for your API gateway and then configure Google as an identity provider for that user pool. This link might be helpful: https://docs.aws.amazon.com/cognito/latest/developerguide/google.html. Cognito even has a hosted UI if you want to use it for signing users in.
As for your question about persisting user sessions, they usually get persisted in local storage in the browser or in a cookie or some similar mechanism. You can also persist them on the server-side in a database like you were mentioning but that isn't really for authentication purposes.
The user session will contain an access token. The access token is short-lived, meaning you can only use them for an hour usually. After that you have to use a separate refresh token to generate a new access token. And to be extra safe the refresh token itself will expires after a few days (and you have to sign back in).
I'm looking at my options for a managed sign-on service and AWS Cognito looks promising.
I notice that it's user pools etc do not currently replicate across regions. I wanted to confirm that 1 region is sufficient us-west-# for example (or us-east-#) would be sufficient for an application that has users spread across Canada, the US and Puerto Rico.
In general, not only in the case of Cognito, the closer your users are in the data center that hosts your services the better. And this is only so you can minimize the propagation delays between your clients and the data center hosting your service.
Therefore, if you have to choose one region, choose the one that the majority of your clients are closer to.
AWS Cognito, does not replicate userPools across regions at the moment. Therefore, if you want to use the AccessToken against that userPool you need to go to the region that the userPool resides.
Now, every other service that accepts accessTokens, will accept your token inside AWS, outside AWS in any region.
I'm adding this supplementary detail to the question as a reference for the token types that Cognito returns. As I just found it by googling some of the info in the answer above.
Using the AccessToken against the userPool would be done for things like updating the user's account information. Which would be required to use the region the pool resides in since pools are not replicated.
http://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html
ID Token
The ID token is represented as a JSON Web Key Token (JWT). The token contains claims about the identity of the authenticated user. For example, it includes claims such as name, family_name, phone_number, etc. For more information about standard claims, see the OpenID Connect specification. A client app can use this identity information inside the application. The ID token can also be used to authenticate users against your resource servers or server applications. When an ID token is used outside of the application against your web APIs, you must verify the signature of the ID token before you can trust any claims inside the ID token.
The ID token expires one hour after the user authenticates. You should not process the ID token in your client or web API after it has expired.
Access Token
The access token is also represented as a JSON Web Key Token (JWT). It contains claims about the authenticated user, but unlike the ID token, it does not include all of the user's identity information. The primary purpose of the access token is to authorize operations in the context of the user in the user pool. For example, you can use the access token against Amazon Cognito Identity to update or delete user attributes. The access token can also be used with any of your web APIs to make access control decisions and authorize operations in the context of the user. As with the ID token, you must first verify the signature of the access token in your web APIs before you can trust any claims inside the access token.
The access token expires one hour after the user authenticates. It should not be processed after it has expired.
Refresh Token
The refresh token can only be used against Amazon Cognito to retrieve a new access or ID token.
By default, the refresh token expires 30 days after the user authenticates. When you create an app for your user pool, you can set the app's Refresh token expiration (days) to any value between 1 and 3650.