So I had an API (let's call it API number 1) and one user pool. The API was used for testing purposes. It called a lambda function to update an IOT shadow. Now I used cognito to create a user pool and added some users in it. Then, I created an authorizer for API number 1 with the same user pool and enabled authorization in POST method execution for it. I created a login form so that I could log into cognito user pool and would get an ID token from it. I used that id token in POSTMAN along with Authorization header and the post worked. When I did not provide the id token, I got message: unauthorized as a response. The IOT shadow was updated only when I provided the authorization header and id token which meant everything went smoothly.
Then for testing purpose I created another API (API number 2), I replicated API number 1 entirely, created an authorizer with the same pool, enabled Authorization, logged in, got the id token used it in POSTMAN with Authorization header (the same process) and it didn't work. I kept getting message: unauthorized.
Then I thought maybe the problem was with API number 2 and created API number 3. This time I also created an entirely new user pool. I used that user pool to create an authorizer. The rest, I replicated API number 1 entirely again. I enabled CORS, in POST method execution I added Authorization. I did everything. Still when I tried again with POSTMAN, it didn't work.
So, API number 1 still functions perfectly like it should. API 2 and API 3 do not work despite having the exact same configurations as API 1.
I really do not know where I am going wrong. I even tried creating separate lambda functions for each API. Even the lambda code is the same (except for the IOT certificates and the IOT shadow URL).
Please, Help!! At this point I think I have tried almost everything and still I don't know whats wrong. One seems to work with the same configuration that the other two have whereas the other two don't. Thanks alot in advance.
Related
Hey I am getting started with the serverless framework, apigateway, lambdas and authorizers.
Here my questions:
In order to verify a proper JWT token (which seems nowadays the best solution for serverless authentication), I would need a client id. Since the authorizer lambda is not capable(?) of reaching any other parameters of the request into the lambda except for the token itself, this is a difficult task to do. How can I achieve this?
Since with every authenticated call, an additional lambda is called, my costs are doubled?! May be I am misunderstanding something here, but it seems to me like implementing a method for verifying my token without using the authorizer is cheaper and I don't need to implement the authorizer lambda itself.
The whole point of OAuth2 is that at the point of authorization you don't care who the bearer presenting you with a token is or which client they are using (web app, Postman, etc.), only that the token is valid for whatever the token bearer is trying to do. You trust that the authentication has happened because the token issuer has done the authentication.
When you talk about the aud(audience) (from comments) in JWTs, which may or may not be included dependent on the JWT issuer, this is intended to reflect the service or services that the JWT is valid for.
This could for example have a value of 'myAPIName' or 'myAPIName/test' or even ['myAPIName/test1', 'myAPIName/test2'].
If you need to validate an individual aud claim you have two choices, you can either have different Lambdas authorizing different api routes and methods with hardcoded aud variables or you can get the name of the api being called and map it back to something that would match an aud claim.
For example the method arn for the incoming request can be found in event.methodArn. This looks like arn:aws:execute-api:{regionId}:{accountId}:{apiId}/{stage}/{httpVerb}/ potentially with [{resource}/[{child-resources}]] dependent on your implementation. With a bit of string manipulation, you could map this back to the format of an audience claim (whatever that looks like for you).
If you would rather work an api name instead of an api name you can use the apigateway.getrestapi method for whatever sdk you are using. Documentation on this method for the JavaScript sdk can be found here.
The JWT may have a sub(subject claim), again dependent on implementation of the JWT issuer, this could relate to any of your users (or at least the users the JWT issuer knows about). Validating this beyond checking the signature of the JWT is pointless. The best you could do is check if that user exists and only if you have access to the same user database that the JWT issuer does. Although this can be used to ensure that UserA only has access to UserA's data. Again, you are trusting that the fact a bearer has a token is proof that they have authenticated (proved who they are).
I hope that answers part one of your question.
In regards to part 2, the advantage of using a Lambda Authorizer over doing the authorization in the target Lambda is caching.
So envisage I have a token valid for one hour and I call your API once every second for 30 minutes (1,800 calls). You have a Lambda authorizer with a response cache time of 10 minutes. That means you check the JWT 3 times for 1800 api calls.
But if you do the validation of that token in your target Lambda, you are doing that processing 1,800 times.
There is authentication with AWS Cognito which will allow you to use authentication outside your application and still being able to let your application divide the users into subgroups based on custom roles or similar.
If for some reason you cannot use AWS Cognito (Why not?) there is both the possibility of custom authentication (the same for each function with SLS) or even authenticating with custom code inside each lambda function.
I would recommend to use Cognito, and only custom if you know you need it.
A simple API endpoint, with a Cognito User Pool Authorizer, when using the Authorizer Test button ( or using postman/Insomnia ) with a valid token fails ( Screenshot bellow ):
I know the token is valid as I can make a successful call to the Cognito user pool user-info end-point using the same token and get the desired response back.
Also removing the authorizer ( setting it to None ), will return the desired response as well.
I've tried both with and without Bearer ..., I've also tried to change the Authorization Token source to method.request.header.Authorization as I've found in some older Question but immediately after saving, it changes it back to Authorization, while method.response.header.Authorization doesn't seem to work either.
The API was deployed through a CloudFormation stack.
I'm writing a complete guide to this issue as the documentation is lacking and it's not easy to find the right information for such a simple task. but it may take a few days, so till then I'll post a short answer here and once ( hopefully ) I finish the guide I'll update this answer:
My problem was that I was using the access_token, but I had to use the identity_token! The other problem is that none of the OAuth2 tools available ( like Auth modules of Postman and Insomnia ) return or use the identity_token, they don't even show the token! and although it is in the OAuth2 specs, nobody's using it ( except Cognito! ),...
So I made some changes to the Insomnia source-code of the OAuth2 module and used the correct token, then it started working!
I'm going to make a PR to Insomnia and if it went through the feature may become available in next releases, otherwise, I'll make my packaged binary available so peep can use it since otherwise, it's a nightmare to get tokens from AWS!
If your API methods - do not have OAuth scopes: must use ID tokens.
If your API methods - have OAuth scopes: must use access tokens.
The test method always uses an id-token. So to use this in Postman - add an OAuth scope to your API methods.
From:
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-enable-cognito-user-pool.html
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.
Strange but I thought I have a similar issue, but I was aware of that in the response there are two tokens and I was trying both and none of them was working.
After reading so many things around the internet, nothing was working.
I went to the ApiGateway user interface, clicked on the authorizer, then edit and I hit save. AND VOILA, it works. Strange, maybe it will help someone else too.
I had the same issue and I tried both id_token and access_token as well but didn't work.
Also tried to redeploy my stack, but didn't work.
I'm using AWS CDK to deploy my stack.
My solution was to go to the user interface, click on the authorizer -> edit -> save without changes. Then I ran the "test" and it worked.
Don't forget to deploy it. I forgot it and spent hours debugging why it is working in the test method, but not working using Postman.
Trying to understand how to use Cognito and API Gateway to secure an API.
Here is what I understand so far from AWS documentation and the Cognito user interface:
Clients
www-public - public facing website
www-admin - administrators website
Resource Servers
Prices - for this simple example the API will provide secured access to this resource.
Scopes
prices.read
prices.write
Again, very simple permissions on the API. Public www users can read prices, administrators can write them.
API Gateway
GET /prices - accessible to authenticated users that can read prices.
POST /prices - only accessible to administrators
Users
Administrators - can update prices via the POST method.
Non-administrators - cannot update prices.
Based on this...
Each client will request the scopes it is interested in. So for the public www site it will request prices.read and for the administration site both prices.read and prices.write.
The API Gateway will use two Cognito Authorisers, one for each HTTP Verb. So the GET method must check the user can read prices and the POST method that they can write prices.
The bit I don't see is how to put all of this together. I can make the clients request scopes but how do they now connect to user permissions?
When the token is generated, where is the functionality that says "Ok, you requested these scopes, now I'm going to check if this user has this permission and give you the right token?"
I understand that scopes ultimately related to the claims that will be returned in the token.For example, requesting the profile scope means that the token will contain certain claims e.g. email, surname etc.
I think based on this that my permissions will ultimately end up being claims that are returned when specific scopes are asked for. The fact that the two clients differ in what they request means that the prices write claim an never be returned to the public www client. It would never issue a token if the prices.write claim was requested.
What I can't see is where this fits in Cognito. There is the option to put users into groups but that is pretty much it. Likewise, there is nothing (that I could see) to relate scopes to claims.
I'm coming from a .Net and Identity Server background. Certainly in the last version of Identity Server I looked at there was a handler method where you would work out which claims to put into a token. I guess this would map into one of the custom handler lambda functions in Cognito. From there this would need to query Cognito and work out what claims to issue?
The final piece of the puzzle is how the API Gateway checks the claims. Can this be done in API Gateway or does the token need to be inspected in the Lambda function I will write to handle the API Gateway request?
Certainly using Identity Server and .Net there was a client library you would use in the API to inspect the claims and redact permissions accordingly. Guessing there is something similar in a Node JS Lambda function?
A few assumptions there as I'm basically in the dark. I think the basics are there but not sure how to connect everything together.
Hoping someone has figured this out.
I have just started with Amazon Cognito and I want to use it for my web application. I want to develop a stateless app, in which I SignUp/SignIn using Cognito and then using the JWT token in rest of the requests.
I have implemented sign-up and sign-in flow in Node.js using amazon-cognito-identity-js package and then using the JWT token to call a lambda function using aws-sdk. Things are as expected till here.
But now the issue is with different user operations like get attribute, verify attribute, update password etc. as listed #
https://docs.aws.amazon.com/cognito/latest/developerguide/using-amazon-cognito-user-identity-pools-javascript-examples.html
All of these operations require cognitoUser object and in the documentation they are using userPool.getCurrentUser(); expression.
And I have read somewhere that this method returns the last authenticated user. So I think this expression userPool.getCurrentUser(); will cause conflicts. For example if UserB logs in after UserA and UserA tries to update his password, it will not work.
Can someone suggests me what are the possible solutions?
Should I store the cognitoUser object in session at server side ?
[This solution breaks my stateless requirement and I will have to maintain session on server side.]
Is there any way to perform these operations using JWT token ?
Please suggest if you can think of any other better approach to implement Cognito in web app.
Thanks.
We have a stateless app using cognito and lambdas.
The way we have set it up is to not call lambdas directly but to use Api Gateway and lambda-proxy integration.
If you call lambdas directly from your front end code and are using the cognito tokens for authentication then you need to put a lot of logic in each lambda to validate the token, e.g. download the relevant keys, check the signature of the jwt, timestamps, issuer etc. If you use API gateway then you can just create a cognito authorizer and place it in front of your lambdas.
We pass the id_token when making api calls, then the call is validated by the authorizer and the lambda receives all the current attributes set up in the user pool. This means we don't need to make additional calls to get attributes.
For changing the user passwords this can be done from the front-end of the app by calling the cognito api with the access_token if you have allowed it in the user pool client setup.
I have a Cognito Identity Pool that is used to authenticate my front end users, as well as give them certain permissions in my application. However, I have encountered an issue with giving these users permission to access IoT, which involves invoking a Lambda calling iot.addPrincipalPolicy(), and once that is done then everything works flawlessly.
However, the issue I am facing is that right now I am running this function is being called every time my user requests authentication, when it really only needs to be ran when the user signs up. Is there a way to make sure that it only gets ran once? I was thinking of using a Cognito User Pool trigger, but that will only work for my users who authenticate with Cognito and not with Facebook or Google.
So basically, I would like to only call this function once, the first time that the user gets an Identity Pool ID. Is there a way I can do this that will work for all login methods?
As I don't have enough rep points to simply put a comment, I will leave this here just in case it helps you.
Cognito User Pool recently gained support for Facebook and Google identity providers, so you COULD user a User pool trigger if needed.
http://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-social.html