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.
Related
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
USER logs in in Amazon Cognito and the App/Web gets an "Access Token" that is used whenever it calls API Gateway (HTTP API or REST API).
The API Gateway is configured to use Cognito User Pool as Authorizer, so if the "Access Token" is valid the call can pass to Lambda.
So, how do I know (inside Lambda) who is the user doing the calls and what are his/her details?
This answer set me on an easy path, but I realized there is an easier one.
If you dump the content received by the Lambda (python code) like this.
And then call the API like this (GET/POST/other depends on how you defined your API)
# curl --request GET --header "Authorization: ${TOKEN}" "${GATEWAY_URL}"
You get a bunch of text. Paste it on https://jsonformatter.curiousconcept.com/ to format it nicely and you will see that within the event you have lots of info like
{
"version":"2.0",
"routeKey":"ANY /*****",
"rawPath":"/default/****",
"rawQueryString":"",
"headers":{
"accept":"*/*",
"authorization":"eyJraW...QiOi",
"content-length":"0",
"host":"*******.execute-api.eu-west-1.amazonaws.com",
"user-agent":"curl/7.52.1",
"x-amzn-trace-id":"Root=1-5ff1***eee7347",
"x-forwarded-for":"**.**.243.124",
"x-forwarded-port":"443",
"x-forwarded-proto":"https"
},
"requestContext":{
"accountId":"****",
"apiId":"*****",
"authorizer":{
"jwt":{
"claims":{
"at_hash":"-pO***Eg",
"aud":"1jk***0n0",
"auth_time":"160***928",
"cognito:username":"357d***a77de4d",
"email":"***#gmail.com",
"email_verified":"true",
"event_id":"19f7e***dc0e80",
"exp":"16***28",
"iat":"16***928",
"iss":"https://cognito-idp.eu-west-1.amazonaws.com/eu-west-1_***8z",
"name":"UserName",
"sub":"357***77de4d",
"token_use":"id"
},
"scopes":"None"
}
},
"domainName":"***.execute-api.eu-west-1.amazonaws.com",
"domainPrefix":"***",
"http":{
"method":"GET",
"path":"/default/***",
"protocol":"HTTP/1.1",
"sourceIp":"***",
"userAgent":"curl/7.52.1"
},
"requestId":"Yi***sA=",
"routeKey":"ANY /***",
"stage":"default",
"time":"02/Jan/2021:23:45:15 +0000",
"timeEpoch":1609631115197
},
"isBase64Encoded":false
}
That is, all the user details are there and you don't have to do anything to get them.
In particular, these 2 are here
event["requestContext"]["authorizer"]["jwt"]["claims"]["email"]
event["requestContext"]["authorizer"]["jwt"]["claims"]["name"]
This has even better implications.
You can leverage on HTTP API Gateway + Lambda for:
Validation of an Access TOKEN (if not valid or expired you get an 'Unauthorized' response)
Extraction of token scopes / details
All this within 130ms (of which you only pay for 3ms). No loading libraries, no manipulating data, no manual decoding, no bulls**t.
The only required work is to configure the User Pool and API Gateway (HTTP or REST type) to do the Authentication for you.
If you wonder where you get the value of TOKEN, it is encoded on the URL that is called after a successful login to Cognito.
Note that you may get in the response URL 2 tokens, ID_TOKEN and ACCESS_TOKEN. To get the user details you need to call the API using the ID_TOKEN.
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 looking to create an API using the Django REST Framework which will authenticate using a separate authentication server by means of its introspection endpoint. The authorization flow should look something like the following.
The client provides either user credentials or a refresh token to the token endpoint on our authentication server.
If the provided credentials or refresh token are valid, the authentication server responds with an access token and a refresh token.
The client then sends the access token to the API when requesting a resource.
The API verifies the provided access token using the introspection endpoint on our authentication server.
The authentication server responds letting the API know if the access token is valid.
If the access token is valid, the API responds to the client with the requested resources.
Step 4 is the part I'm after, and the Django OAuth Toolkit looks like it provides an option for exactly this. In the section about setting up a separate resource server it states that it allows the application to verify access tokens by use of an introspection endpoint.
So I followed the setup for the Django OAuth Toolkit, and pointed the RESOURCE_SERVER_INTROSPECTION_URL toward the introspection endpoint on our authentication server. Then I acquired an access token from our authentication server and provided it to the API as an Authorization header, but I get the following response.
Content-Type: application/json
WWW-Authenticate: Bearer realm="api",error="invalid_token",error_description="The access token is invalid."
Vary: Accept
Allow: GET, HEAD, OPTIONS
Content-Length: 58
{
"detail": "Authentication credentials were not provided."
}
If I don't provide a token I get the same response body, but no WWW-Authenticate header. The strange part is that the introspection endpoint never receives a POST request, which it should be sending to verify the access token.
So did I misread the documentation, or am I doing something wrong? Why isn't this working as I expect?
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