I am working on aws cognito with bearer token.
Below is the code to setup Bearer configuration.
I have written code to login via user name & password
I am able to logged in successfully and get the token
But when i am trying to access my authorise API it is throwing below error.
Could you please help me to resolve this?
Looks like your system is failing when trying to download OpenID Connect metadata. This will be a URL such as the following - so you should make sure your API is configured with a URL you can reach in the browser:
https://cognito-idp.eu-west-2.amazonaws.com/eu-west-2_qqJgVeuTn/.well-known/openid-configuration
The following type of code should work when validating Cognito tokens in .NET, if you add the Microsoft.AspNetCore.Authentication.JwtBearer library. Note that Cognito does not issue an Audience claim so you need to avoid validating it:
services
.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options =>
{
options.Authority = "https://cognito-idp.eu-west-2.amazonaws.com/eu-west-2_qqJgVeuTn";
options.TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters {
ValidateIssuer = true,
ValidateAudience = false,
};
});
Note that this includes a website library in APIs and expected OpenID Connect endpoints to exist. Personally I prefer not to write OAuth secured APIs like this.
JWKS ENDPOINT
The standard way to do API token validation is for the API to only know about the JWKS endpoint, as in these examples:
Node.js API JWT Validation
Java API JWT Validation
I found this approach a little harder in .NET, where libraries didn't quite do what I wanted. Here is some code that shows how to use extensibility points, in case useful:
.NET API JWT Validation
Related
I'm providing an external-facing REST GET API service in a kubernetes pod on AWS EKS. I had configured an ALB Ingress for this service which enforces Cognito user pool authentication. Cognito is configured with Authorization code grant with the openid OAuth scope enabled.
If I invoke my REST API from the browser, I get redirected to the Cognito login page. After a sucessful authentication on the form here, I can access my REST GET API just fine. This works, but this is not what I'd like to achieve.
Instead of this, I would need to use a Bearer token, after getting successfully authenticated. So first I invoke https://cognito-idp.ap-southeast-1.amazonaws.com using Postman with the request:
"AuthParameters" : {
"USERNAME" : "<email>",
"PASSWORD" : "<mypass>",
"SECRET_HASH" : "<correctly calculated hash>"
},
"AuthFlow" : "USER_PASSWORD_AUTH",
"ClientId" : "<cognito user pool id>"
}
and I get a successful response like:
"AuthenticationResult": {
"AccessToken": "...",
"ExpiresIn": 3600,
"IdToken": "...",
"RefreshToken": "...",
"TokenType": "Bearer"
},
"ChallengeParameters": {}
}
In the last step I'm trying to invoke my REST API service passing the Authorization HTTP header with the value Bearer <AccessToken> but I still get a HTML response with the login page.
How can I configure Cognito to accept my Bearer token for this call as an authenticated identity?
Quoting AWS support on this topic: "the Bearer token can not be used instead of the session cookie because in a flow involving bearer token would lead to generating the session cookie".
So unfortunately this usecase is not possible to implemented as of today.
STANDARD BEHAVIOUR
I would aim for a standard solution, which works like this:
API returns data when it receives a valid access token, or a 401 if the token is missing, invalid or expired - the API never redirects the caller
UIs do their own redirects to the Authorization Server when there is no token yet or when a 401 is received from the API
If it helps, my OAuth Message Workflow blog post demonstrates the 3 legged behaviour between UI, API and Authorization Server.
API GATEWAY PATTERN
It is perfectly fine to use an API Gateway Design Pattern, where token validation is done via middleware before hitting your API.
However that middleware must return a 401 when tokens are rejected rather than redirecting the API client.
IMPACT OF APIs REDIRECTING THE CLIENT
This may just about work for web UIs, though user experience will be limited since the UI will have no opportunity to save the user's data or location before redirecting.
For mobile / desktop apps it is more problematic, since the UI must redirect using the system browser rather than a normal UI view - see the screenshots on my Quick Start Page.
CHOICES
Any of these solutions would be fine:
Possibly the middleware you are using can be configured differently to behave like a proper API Gateway?
Or perhaps you could look for alternative middleware that does token validation, such as an AWS Lambda custom authorizer?
Or do the OAuth work in the API's code, as in this Sample API of mine
MY PREFERENCE
Sometimes I prefer to write code to do the OAuth work, since it can provide better extensibility when dealing with custom claims. My API Authorization blog post has some further info on this.
Amazon Web Services introduced a beta release of HTTP API as a new product on API Gateway early last month. Its authentication is managed using JSON Web Tokens and configured with a form asking for
"Name of the Authorizer"
"Identity Source... a selection expression that defines the source of the token"
"Issuer URL"
I'm not very familiar with authentication protocols at all or what these form fields are asking, and currently the documentation from AWS on how to configure this to work with Cognito is sparse. I'm not totally comfortable configuring this without guidance due to my lack of experience. Another Stack Overflow user seemed to have a similar issue but didn't get an answer.
AWS is using JWT Bearer Grant for this purpose.
Draft Specification here.
It allows HTTP API Gateway to accept JWT Tokens in the incoming Authorization HTTP header containing a self-contained JWT access token issued by third-party authorization servers (like Cognito, Azure AD, etc).
API Gateway validates the incoming JWT Token by matching the 'iss' value with the issuer URL to see if it can trust this token.
Try with these values.
Name of the authorizer: Registered client name in your Cognito User Pool .
Identity Source: Leave it as default, $request.header.Authorization .
Issuer URL: Check the metadata URL of your Cognito User Pool (construct the URL in this format :: https://cognito-idp.[region].amazonaws.com/[userPoolId]/.well-known/openid-configuration :: look for a claim named "issuer". Copy its Value and paste it here.
Audience: Client ID of your Registered client in Cognito
Good Luck!
cheers,
ram
Used #ram answer to get through, and was able to implement this
1.Name of the authorizer:
AWS Cognito > User pools > App Integration > App client settings > App client :
Example : xxxxxx_app_clientWeb
2.Identity Source : $request.header.Authorization
3.Issuer URL
construct the URL to get Cognito user pool metadata ( https://cognito-idp..amazonaws.com//.well-known/openid-configuration)
Example :
https://cognito-idp.us-east-1.amazonaws.com/us-east-1_FcgSrx2141/.well-known/openid-configuration
open the URL and you will see a json
take the "issuer" value
Example :
"issuer":"https://cognito-idp.us-east-1.amazonaws.com/us-east-1_FcgSrx2141"
Take: https://cognito-idp.us-east-1.amazonaws.com/us-east-1_FcgSrx2141
4. Audience: AWS Cognito > User pools > App Integration > App client settings > App clientID
Example :
ID 9sptej55gii5dfp08ulplc343
Take: 9sptej55gii5dfp08ulplc343
This video explains the whole process and configuration like no other.
https://www.coursera.org/lecture/building-modern-java-applications-on-aws/use-amazon-cognito-to-sign-in-and-call-api-gateway-s226R
I am thankful that the video is public.
Note: (As far as I know) The course is from AWS but offered to the public through different MOOC websites (not just this one).
Once you have read & played enough, you will start seeing the gems within the details.
Token for example, is mentioned in many docs, but it can be Access / Id / Refresh Token. If you don't realize about this you can be wasting your time.
For example the "Implicit grant" doesn't provide a Refresh-Token, so you cannot renew your Access-Token and trying to do it is useless.
I am running a working AWS Cognito service on a frontend application which can successfully do the basic stuff - login, logout, signup, etc..
Right now I am trying to get user attributes through the backend API, such that:
1) The user login in the application and gets a JWT.
2) The JWT is being sent to the backend server.
3) The server has to extract the email of the user by using the access token
The closest thing that I found to what I need is this Cognito service.
So I am making a GET request to "https://mydomain.auth.eu-central-1.amazoncognito.com/oauth2/userInfo"
With Authorization Header as they are asking for, but I keep getting this response:
{
"error": "invalid_token",
"error_description": "Access token does not contain openid scope"
}
I have tried searching for this error but couldn't find any explanation about the error.
Thanks by advance
Erez, are you using a custom UI?
Because the custom UI uses flows that are completely separated from the OAuth2 ones (USER_SRP_AUTH, USER_PASSWORD_AUTH). Tokens that are released with these flows are not OpenID Connect compliant (basically they don't contain the openid scope) so you cannot use them to gather user infos (since the userinfo endpoint is OpenID Connect compliant and needs to be invoked with jwts compliant with OIDC standard).
We're also struggling on that, i'm sorry.
I had this exact problem and it was my fault. I was sending the id_token instead of access_token property of the token.
I program in PHP, so I was sending as header "Authorization: Bearer ".$token->id_token instead of "Authorization: Bearer ".$token->access_token. Now it works.
Hope it helps you or someone.
I am still experiencing the same issue. My problem relies on programmatic use of signIn service (not Hosted UI via federated login) in Amplify framework. After a long googling, I have discovered that this is because "openid" is not including in the scope of token. Only "aws.cognito.signin.user.admin" is included.
You can find a reference here, thread is still open https://github.com/aws-amplify/amplify-js/issues/3732
This solution seems to be fine for me How to verify JWT from AWS Cognito in the API backend?
If I understand correctly, you are successfully getting the #id_token sent to your front end from Cognito (steps 1-3). You can enable scopes on the #id_token by selecting the following options in your Cognito Pool App Client Settings:
I had a similar issue and I spent a couple of hours to find a solution. The access token you received it from cognito in your frontend application you need to send it to your backend then decode it and verify it. here is a good documentation from aws: https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html
Is there a way to authenticate the Microsoft or google OAuth token in active directory without using an authentication server?
Here is the scenario:
A client app gets an Microsoft access_token from some external service.
Client app will make a call to some secured web API and pass that access_token along with the request header
If the access_token passed by client is valid then API will provide response to the client.
Is there a way to validate that access_token on API side?
My normal understanding about OAuth 2.0 is there needs to be an authentication server to which both the client and API would talk to as shown in the figure below:
But if the token is provided by some external service, Can we use it to validate our web API. Are there any ways to implement such authentication?
You can learn more about AAD Signing Keys and handling Key Rollover using this page: Signing key rollover in Azure Active Directory
Validation of the token, once you have the signing key, can be done using existing libraries like OWIN. You can also try following instructions like this (although it seems the document isn't 100% complete yet): Manually validating a JWT access token in a web API
This library is also available, but I think OWIN is supposed to have replaced it in general.
Also check out this blog post, which has a pretty great deep dive into token validation.
Let's say I have an AngularJS application that consumes the REST API of a Django application.
The Django application has got a built-in OAuth2 provider that can be called to retrieve an access token and use the protected endpoints of the API. This provider is using django-oauth-toolkit.
Let's assume there is a registered client with "password" grant type, so that the end users only need to provide their credentials in the front-end in order to get an access token from the back-end.
At some point we want to add some support for social networks login and we decide to use python-social-auth (PSA) to that end. Here is the workflow I want to achieve:
The user logs in on Facebook from the front-end (via the Facebook SDK) and we get an access token back from the OAuth2 provider of Facebook.
We send the Facebook token to an endpoint of our REST API. This endpoint uses the Facebook token and django-social-auth to authenticate the user in our Django application (basically matching a Facebook account to a standard account within the app).
If the authentication succeeds, the API endpoint requests an access token from the OAuth2 provider for this newly authenticated user.
The Django access token is sent back to the front-end and can be used to access the REST API in exactly the same way that a regular user (i.e. logged in with his credentials) would do.
Now my problem is: how do I achieve step 3? I first thought I would register a separate OAuth2 client with Client Credentials Grant but then the generated token is not user-specific so it does not make sense. Another option is to use the TokenAuthentication from DRF but that would add too much complexity to my project. I already have an OAuth server and I don't want to set up a second token provider to circumvent my problem, unless this is the only solution.
I think my understanding of PSA and django-oauth-toolkit is not deep enough to find the best way of reaching my goal, but there must be a way. Help!
I managed to get something working using urllib2. I can't speak towards whether or not this is good practice, but I can successfully generate an OAuth2 token within a view.
Normally when I'd generate an access token with cURL, it'd look like this:
curl -X POST -d "grant_type=password&username=<user_name>&password=<password>" -u"<client_id>:<client_secret>" http://localhost:8000/o/token/
So we're tasked with making urllib2 accomplish this. After playing around for some bit, it is fairly straightforward.
import urllib, urlib2, base64, json
# Housekeeping
token_url = 'http://localhost:8000/auth/token/'
data = urllib.urlencode({'grant_type':'password', 'username':<username>, 'password':<password>})
authentication = base64.b64encode('%s:%s' % (<client_id>, <client_secret>))
# Down to Business
request = urllib2.Request(token_url, data)
request.add_header("Authorization", "Basic %s" % authentication)
access_credentials = urllib2.urlopen(request)
json_credentials = json.load(access_credentials)
I reiterate, I do not know if this is in bad practice and I have not looked into whether or not this causes any issues with Django. AFAIK this will do this trick (as it did for me).