Can anyone please help me with this Use-case?
Use-case : I've created the secure proxy for a private resource in the AWS API gateway. For private integration I've used VPClink and configured the Cognito pool authorizer. But the backend private API already have some Oauth2 token configured and I've separate API to generate the OAuth2 token. I don't want the end client to send both token via api gateway request, But want to internally pass the token which is already configured on the backend private rest API, via API Gateway.
For now I've created the proxy and I'm passing both tokens via request.
Note : I don't want to use lambda function.
For Example: You tried to hit the API Gateway Endpoints via postman with all the required parameters, now the request should first go to authenticator endpoint to generate the Oauth2 Token, Once token is generated the token should be passed internally to actual backend private resource to return the response.
Also, I want to know if it's the best approach to pass backend API token internally or we can pass both tokens i.e. Backend API Token and API Gateway authorizer token, via request.
Related
So I'm going to put a public facing API up using AWS API Gateway, where I'll have back end lambda resources that handle the logic for each route (decoupled microservice).
What should I be storing in the JWT? Currently, I've disabled all read attributes, so the token only contains cognito:username, where in my database I will store this as the user id for each user. My understanding is that once a JWT is properly generated, I can use Cognito as an authorizer with API Gateway, and then once the token JWT details are received at the lambda layer, all I need to do is use the cognito:username key to lookup the user profile in my database.
Should I be implementing any other checks in the backend, or is it safe to rely on API gateway to pass the authenticated request?
Thanks!
The cognito API Gateway authorizer will only check if the token has not expired and if it belongs to the correct user pool. But since you will be extracting username from the token itself, you should be safe. Just make sure to configure API Gateway to pass Authorization header to the lambda, it does not do this by default.
I want to Authorize the request to API Gateway using COGNITO_USER_POOLS or API Key, That is the incoming request can have either of authentication token(using COGNITO_USER_POOLS) or API Key
Is there anyway to configure both types of authorization and use either of one of them to authenticate on a single API Gateway resource?
The test enviornment for the API Gateway..... Cognito Authorizer.
What value is it expecting ?
I tried to use accessKeyId returned from CognitoIdentityCredentials and it did not work.
Identity Flow
'Testing the accessKeyId gives Error
I also tried _identityId and that did not work as well.
The error for both is "Unauthorized request"
I think your API endpoints are protected by AWS_IAM authorization method. you can confirm it from the Method Execution section of your API endpoint.
If you are using AWS_IAM method, the api end points excepts a signature to be generated using your aws credentials and pass it in the request under the Authorization header.
You can use postman app to test the endpoint, follow these steps
create a new request with the correct http method and the url
under Authroization tab, select AWS Signature
Enter the values for AccessKey, Secret Key
under the Advanced section, enter your region and Session Token
Postman application is very handy to test rest api endpoints. it's even handy to test the api gateway endpoints protected by AWS_IAM authorization method. The postman app generates the signatures required using your AWS credentials and include the generated signature part of http headers of the request.
Note: Also make sure your identity pool's Authenticated role has permission to invoke the api endpoint.
Reference:
https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-use-postman-to-call-api.html
you can download postman application if you dont have - https://www.getpostman.com/downloads/
When using a AWS Cognito attribute from a JWT token in a lambda, do I need to verify the JWT? The Lambda is only triggered by an API Gateway which already verifies the token.
Adding details:
- I'm using Cognito Authorizer in the API Gateway to verify the token.
- The lambda is connected to the API Gateway as proxy.
No you don't need to verify the JWT in backend lambda if protected by a custom lambda authorizer by API Gateway. I would suggest you to use REQUEST based lambda authorizer and attach attributes in the response. So your backend lambda will be able to access attributes in event.requestContext.authorizer['your_attribue'].
This will also enable you to test your Lambda in isolation without needing to get attribute from JWT. You can always mock the event object for unit testing.
I ran into the same conundrum, and was trying to find documented confirmation that, within the Lambda, I wouldn't have to do any validation on my own, and that I can safely rely on the the token / claims being genuine. Unfortunately, nothing in the AWS documentation or the forum posts that I've seen so far has explicitly confirmed this.
But I did find something similar for GCP, and how the API Gateway there validates the JWT. From the GCP documentation:
To authenticate a user, a client application must send a JSON Web
Token (JWT) in the authorization header of the HTTP request to your
backend API. API Gateway validates the token on behalf of your API, so
you don't have to add any code in your API to process the
authentication. However, you do need to configure the API config for
your gateway to support your chosen authentication methods.
API Gateway validates a JWT in a performant way by using the JWT
issuer's JSON Web Key Set (JWKS). The location of the JWKS is
specified in the x-google-jwks_uri field of the gateway's API config.
API Gateway caches the JWKS for five minutes and refreshes it every
five minutes.
So, it seems that within GCP at least, we don't have to do anything, and the API Gateway will handle everything. Even though this is not a confirmation that this is how it works in AWS as well, but the fact that this is how it works in GCP, it gives me some more confidence in assuming that it must be so in AWS too.
I am entirely newbie in Amazon Web services. Currently i am developed a REST API service using Laravel's micro frameworks called Lumen. I am using passport for token based authentication and all that working fine. I need a proxy server to hide my actual endpoints and do some other functionality so i am planning to use AWS API Proxy Gateway and host the API endpoints in EC2 instance.
i went through Build an API with HTTP Proxy Integration from Aws documentation. but there is nothing about using a custom authentication using Oauth.
My Doubts are
How to use Passport authentication when using AWS API Gateway
Is there any good method to hide my REST Endpoint from customer and need a way to change the proxy end point from time to time.
I don't know Laravel ecosystem, but:
if passport expose something like an OpenId Connect you could use Cognito Federated Identities for, precisely, federate your identity, and associate the authorized identities with a given IAM role and unauthorized with another role;
you can use an Api Gateway Custom Authorizer to perform fully customizable auth;
Try expanding your question so we could add more details...
Yes, like what BAD_SEED said, you can use API Gateway Lambda authorizer (formerly known as the custom authorizer) to do any logic to verify the token, since it's just a javascript package.
So, one option is like what auth0 does in (https://auth0.com/docs/integrations/aws-api-gateway/custom-authorizers/part-3) and (https://github.com/auth0-samples/jwt-rsa-aws-custom-authorizer). Their sample authorizer does followings:
It confirms that an OAuth2 bearer token has been passed via the Authorization header.
It confirms that the token is a JWT that has been signed using the RS256 algorithm with a specific public key
It obtains the public key by inspecting the configuration returned by a configured JWKS endpoint
It also ensures that the JWT has the required Issuer (iss claim) and Audience (aud claim)
But unfortunately, Passport does not support JWKS endpoint (which exposes public key for the token signature). So you may have to expose it by yourself.
Another option is much easier, you just make a token verification endpoint in your application, something like /users/me, and protect it with auth middleware. Then in your Lambda authorizer, call it with the token in the request to your other micro service endpoints. By this way, all token verification stuff is left to Passport, and the authorizer just executes policy based on the result of the verification.
Not very sure about what you want to reach, but API Gateway is just a proxy, so you can certainly change backend side endpoints for its frontend one, which is better not changing so often.