We have a serverless backend which is protected by IAM in API Gateway. We have another in-house authentication solution and we want to support both Authentication mechanisms in our service. I was planning to write a Custom Authorizer with authentication chain supporting multiple Authentication.
However, I couldn't find any way to validate AWS Sigv4 signature on backend. I found AWS docs on how to sign a request or calculate Sigv4 signature ([1], [2], [3] and [4]), however all these docs are from client perspective in which client will have access to ACCESS_KEY_ID, SECRET_ACCESS_KEY and SESSION_TOKEN. When custom authorizer lambda will receive the request it'll have only ACCESS_KEY_ID (in Authorization header) and SESSION_TOKEN (as additional header). So re-calculating signature on backend is not possible. How can I validate the signature at the backend to authenticate?
This post might be a duplicate of How to verify AWS SigV4 signing which is still unanswered. Solution suggested in this question still need SECRET_ACCESS_KEY.
[1] https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html
[2] https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-examples-using-sdks.html
[3] https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html
[4] https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html
(Caveat: I'm talking out my ass a bit here and haven't tried to implement this myself, just going off first principles.)
My understanding is that SigV4 is symmetric crypto, since it's using HMAC which is symmetric. That implies that there's no way for your lambda (an untrusted 3rd party) to verify the signature without having the key itself (in this case, the "secret access key"). If you had that key, well, you'd be able to impersonate that user. Probably undesireable :P
With a session token, you have to include the session token in a request header, as you mentioned (probably because otherwise no one could tell which session token you signed it with; there's no corresponding AWS_SESSION_TOKEN_ID). That means you actually could verify the signature, but only the request's integrity: you don't know if that session token actually belongs to the user in question.
So I think you're hooped unless AWS verifies it for you.
Related
I am using the following doc by AWS for verifying the incoming token with Cognito to verify the user in cognito pool:
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-verifying-a-jwt.html
Now I also need to verify one of the custom attributes (email) of that user. (Basically this is to mitigate a case where some user can change their email-id in the API payload to access someone else's details).
The Cognito SDK I found to do this was this : https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html
It works just fine, however this led me to a question :
Since I'm sending access token in this SDK, do I need to use the former jwt-based token verification as well? Because this SDK also handles the case where token is invalid/expired and sends error codes accordingly. Is there something I'm missing which the former case handles and the latter one doesn't ?
Short answer: no, you can ignore the contents of the JWT.
Longer answer: JWT tokens provide a fast way to verify that a user has been authenticated, without the need to check a database or external service. This can be very important in a high-volume application.
However, they have several limitations:
A JWT token is issued with an expiration timestamp. If you rely on the JWT, you do not have a way to forcibly log-out a user until that timestamp expires.
To be secure, your JWT token must be signed using an asymmetric keypair (I mention this simply because a lot of people have implemented their own identity servers incorrectly; Cognito does it right).
The claims that are in the token (and are signed by the identity server) may not be sufficient for your needs. Best practice is to minimize the size of the token, and iirc Cognito follows this practice by only including the user attributes that are directly tied to authentication.
If any of these limitations apply to a particular use-case (and it sounds like the third applies to you), then you'll have to make that external service call to the identity server. And if you do that, and the server reports authentication status, then there's no need to pay attention to the token.
I read about JWT and i think i understand how it works, but when things come to ballerina examples i don't understand anything:
How do i set the algorithm which i want to use along with JWT and the expiration time?
How do i use a custom private key?
How can i get the token from this example for instance "https://ballerina.io/learn/by-example/secured-service-with-jwt-auth"?
May be how can i get the token using CURL (for testing purposes)?
Also i'm wondering how to use the JWT without the need of having a database with users and passwords..
I'm absolutely new to security and ballerina also. Can anybody help please?
Ballerina JWT module [1] provides following functionalities.
Issue a JWT
You can issue/generate a JWT by providing jwt:JwtIssuerConfig. You can configure username, issuer, audience, expiration time, signing algorithm, custom claims and configuration for signature (key-store config). Please refer to API docs of jwt:JwtIssuerConfig [2]. Example code can be found at [3].
Validate a JWT
You can validate a JWT by providing jwt:JwtValidatorConfig. You can configure expected issuer, expected audience, clock skew, cache configuratons and configurations for validating signature (trust-store config). Please refer to API docs of jwt: JwtValidatorConfig [4]. Example code can be found at [3].
Secure a service with JWT
You can use JWT to secure and HTTP service. The Authorization header of the inbound HTTP request will get validated and authenticated according to the provided configurations. Please refer to API docs of jwt:InboundJwtAuthProvider [5]. Example code can be found at [6].
Calling to a service with JWT
You can use JWT to call to an external server which is authenticated with JWT. The outbound HTTP request is prepared with the Authorization header according the provided configurations. Please refer to API docs of jwt:OutboundJwtAuthProvider [7]. Example code can be found at [8].
Answers for the questions:
How do i set the algorithm which i want to use along with JWT and the expiration time?
You can configure jwt:JwtIssuerConfig [2] as described above.
How do i use a custom private key?
You can configure the jwt:JwtKeyStoreConfig field of jwt:JwtIssuerConfig [2], with your custom private key.
How can i get the token from this example for instance "https://ballerina.io/learn/by-example/secured-service-with-jwt-auth"?
May be how can i get the token using CURL (for testing purposes)?
This is a sample service which is secured with JWT. The token used to invoke this service is provided at the bottom of the sample. How to invoke this service with CURL is also provided.
Also i'm wondering how to use the JWT without the need of having a database with users and passwords..
All of the above samples, does not need any database or file store. All the configurations are provided in the code itself. If there is any requirement to retrieve data from database, that is also possible.
References:
1 https://ballerina.io/learn/api-docs/ballerina/jwt/index.html
2 https://ballerina.io/learn/api-docs/ballerina/jwt/records/JwtIssuerConfig.html
3 https://ballerina.io/learn/by-example/jwt-issue-validate.html
4 https://ballerina.io/learn/api-docs/ballerina/jwt/records/JwtValidatorConfig.html
5 https://ballerina.io/learn/api-docs/ballerina/jwt/objects/InboundJwtAuthProvider.html
6 https://ballerina.io/learn/by-example/secured-service-with-jwt-auth.html
7 https://ballerina.io/learn/api-docs/ballerina/jwt/objects/OutboundJwtAuthProvider.html
8 https://ballerina.io/learn/by-example/secured-client-with-jwt-auth.html
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.
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 JWT token from AWS Cognito. The token is obtained via a call to getOpenIdTokenForDeveloperIdentity and I'm using the flow for AWS Cognito Developer Authenticated identity
The token is hashed with SHA512 and signed with Amazons RSA private key for the region/zone I'm using.
How can I externally verify the signature with python?
Answering my own question here in the hope it helps somebody.
In my case I wanted to verify the signature of a JWT token obtained via the AWS Cognito Developer Authenticated identity route. No AWS API Gateway involvement.
Like many posters on various sites I had trouble piecing together exactly the bits I needs to verify the signature of an AWS JWT token externally i.e., server side or via script
I think I figured out out and put a gist to verify an AWS JWT token signature. It'll verify an AWS JWT/JWS token with either pyjwt or PKCS1_v1_5c from Crypto.Signature in PyCrypto
So, yes this was python in my case but it's also doable easily in node (npm install jsonwebtoken jwk-to-pem request).
I attempted to highlight some gotchas in the comments because when I was trying to figure this out I was mostly doing the right thing but there were some nuances like python dict ordering, or lack there of, and json representation.
I've also noticed some questions around about doing the validation using the signers Certificate. I'll amend my gist to show this also.
Hopefully it may help somebody somewhere.