We are using vertx oauth2 components to implement login with cognito using oauth2 authorization code grant. We could implement the scenario using existing APIs. But vertx expect token introspect path in it's oauth2 config. Otherwise there is no way to ask from cognito whether the provided token to the resource server is correct or not. Anyway we could not find any information on what is the token instrospect context path on cognito documentation.
OAuth2ClientOptions oAuth2ClientOptions = new OAuth2ClientOptions()
.setClientID("***************************")
.setIntrospectionPath("") //what should goes here
.setClientSecret("********************")
.setSite("*****************")
.setTokenPath("/oauth2/token")
.setAuthorizationPath("/oauth2/authorize")
.setFlow(OAuth2FlowType.AUTH_CODE)
There is no introspection endpoint for AWS Cognito so you have to use a different approach:
Download token signing keys from the JWKS endpoint
Use a library to verify the token signature
If it helps, here is some nodejs code of mine that validates Cognito tokens.
I've not used vertx but it seems to support JWT Validation. Usually this involves including the JWKS or metadata URL in an Options object.
Related
Is there any endpoint in AWS Cognito to validate the bearer token?
I am using cognito as my oauth provider and I am able to get the bearer token successfully with app client id and secret.
Now I have to make a call to cognito, to cross verify if it really generated this token and validate the authenticity of the token from my application.
Cognito issues JWT tokens, so you must validate them via a library, which will download the token signing public key from Cognito's AWS endpoint.
Here is an API example in AWS, that validates access tokens using Node.js. A front end app could use similar validation for ID tokens:
JWT Validation Code
If you have particular technology preferences, post back and I'll recommend a library.
I have a service protected with OAuth. For it to use, you first require a token.
I have an app, that has only access to an Apigee proxy. I would like Apigee to do the authentication for the client (app), and setup protection with an API key for the client in Apigee. How do I do that?
I think what you are trying to do is what Apigee refers to as Last Mile Security. Unfortunately, it's not as simple as adding a policy and configuring it with a token URL, client ID, and secret. You'll want to make sure you securely store the credentials, cache the token appropriately, and pass the token on to the proxy target.
Fortunately for you, Apigee has a demo project that does what I believe you are trying to do. Basically, your proxy will be configured with simply the Verify API Key Policy (Do this first as if the api key isn't correct, no need to do all the OAuth handshaking). Once confirmed, you can use Javascript policies to check the cache for a token, and then call the OAuth token endpoint to get one if there is a cache miss. I believe it then uses the AssignMessage policy to set the Authorization header to the token. (Note that the example project does not include the Verify API Key policy, but that should be easy enough to add)
Additionally, the demo project stores the client ID and secret in a js file, which I would not recommend. Maybe store it in an encrypted KVM entries?
The Outbound OAuth sample project can be found here.
please refer to below videos for using oauth authentication in your API proxies:
https://www.youtube.com/watch?v=zn94GhcdgHc&list=PLsWqc60hQz4clQ4ykjCu4qyEhdKe11Lvy
You can use Ouath2 - client credential grant Type, that implies that you must add and configure security policies in your proxy, check the following link that explains this flow.
https://docs.apigee.com/api-platform/security/oauth/oauth-20-client-credentials-grant-type
I'm developing a set of microservices exposed as REST through WSO2 API manager.
Now, I'd like to call these services in Angular front end. What is the best way to handle user authentication and authorization?
I found it can be done through OAuth2 Password Grant as described here?
When user logs in, user credentials will be sent to specific WSO2 APIM endpoint (/token), it validates, generates the token and this token will be sent in header for subsequent calls.
Is this the best approach to this case?
Thanks in advance,
As mentioned in your question, https://apim.docs.wso2.com/en/next/learn/api-security/oauth2/grant-types/password-grant/
This method will only work when you have the resource owner's username and password.
Take an example, suppose you have published the APIs and created a user (resource owner) in the WSO2 store. this user is subscribed to the API using the application. the application will have a client id and secret, which will be used to generate the OAuth2.0 token. this token will be used to invoke the APIs.
Now in your angular project, one way is to hardcode the base64(clientid:clientsecret) and call the token API to generate the OAuth2.0 bearer token. use the generated token to call the APIs onboarded on WSO2. To protect your APIs from the attack, use rate limiting based on IP
Now take another situation, if you want the user to authenticate first, then generate the JWT token for that user using the password grant type (using actual user's username and password), and using that JWT generate the OAuth2.0 Bearer token which will be used to call the APIs.
Steps to be performed for the second situation:
during registration (from Angular), internally onboard the user in the WSO2 Identity Server. (There is a WSO2 API for the same)
After registration, generate the JWT token from the identity server by authenticating username and password. (Again for this, WSO2 API is there)
now using this JWT token, Generate the OAuth2.0 token from WSO2 APIM
use this token to call the APIs
The second approach is the ideal approach for user to service authentication and authorization using WSO2 as the gateway while the first approach mainly focuses on service to service authentication and authorization
Hope this answers your question
Reference Link: https://medium.com/wso2-learning/how-to-protect-your-apis-with-self-contained-access-token-jwt-using-wso2-api-manager-and-wso2-75673d8a4686
Code snippets for Building OAuth 2.0 credentials :
Credential credential = new GoogleCredential.Builder().setTransport(httpTransport)
.setJsonFactory(jsonFactory)
.setClientSecrets(myAppClientID, myAppSecret)
.build();
credential.setRefreshToken(userRefreshToken);
I am using Java Library in order to get the Google Analytics Data.
I do have Client ID, Secret and Refresh Token. I am accessing Google Analytics API though this credentials information,
My question is, Will Google OAuth 2.0 take care of Access Token Automatically? Or Do i need to handle it manually with some mechanism? If i am not passing access token to this code.
From the Credential API doc:
Thread-safe OAuth 2.0 helper for accessing protected resources using
an access token, as well as optionally refreshing the access token
when it expires using a refresh token.
So if you don't specify an access token, it will be automatically fetched using the refresh token. But since you already have an access token, I would say it's good to set it - it will save the first network call to the /token endpoint.
I am working on a mobile application that uses an api built with ASP.NET web api framework. We decided to use ACS alongside a custm STS as a mechanism to secure the api.
We are using a custom STS because we need to authenticate users against our own identity store.
The information flow is as follows:
Mobile app calls the custom STS with user credentials.
User is authenticated against our own identity store.
Once user is authenticated an authorization code is retrieved from ACS and used to retrieve an SWT access token.
Token is returned to mobile app.
Mobile app embeds access token in authorization header and fires request to API
HTTP module in API validates the access token and data is returned if the token is valid.
Everything is done over SSL as we are using oAuth 2.0.
The problem with oAUth 2.0 is that it is at risk from man-in-the-middle attack as the SWT token issued by ACS is a raw token and not encrypted in any way. It is however, signed using a 256bit symmetric key.
We are using swt tokens because we are using an http based approach and the token fits nicely into the auth header of an http request.
Microsoft have provided some ACS security guidelines in the following post:
http://msdn.microsoft.com/en-us/library/windowsazure/gg185962.aspx
we currently implement 2 of these as we check the issuer and the audience i.e that the token was issued by our trusted issuer (ACS) and that the token was issued for the correct audience (our api).
our scenario is based on the following article:
http://msdn.microsoft.com/en-us/library/hh446531.aspx
as such WIF is not used to handle incoming tokens. WIF is only used in claims processing.
given the above mentioned scenario is there anything else that we could be doing to improve the implementation we have to secure our rest based api?
any and all comments/criticism/suggestions welcome.
Thank you.
I think you're already taking the correct approach. The most important thing is to verify if the token is signed by ACS. Never share your ACS secret key with anyone else. If they don't know the key, they cannot forge the signature.
Also do not store confidential information in the token (such as password, credit card number, etc.). You should expect the token may be obtained by someone else, but no one can forge a token with the correct signature.