I deployed REST API gateway on AWS and configure it as a http pass through to my website. When I open API gateway endpoint in browser, it will show my website which is expected.
Now I am going to authenticate API gateway endpoint with cognito and I have configured it by this instruction: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html
So in API gateway, I added a authorizer and put cognito user pool with it.
what I am expecting is when open the API gateway endpoint in browser, it opens cognitor popup dialog to ask for username and password. But I can open the endpoint to view the website without any authentication. It seems configure the authorizer doesn't have any impact on my API. What did I do wrong?
API gateway can't open cognito popup as you are accessing API and there is no application. You need to get authorization token separately and pass this token in Authorization header while calling API. Process is described in doc link that you have mentioned.
To call any API methods with a user pool enabled, your API clients perform the following tasks:
Use the Amazon Cognito CLI/SDK or API to sign a user in to the chosen user pool, and obtain an identity token or access token.
Use a client-specific framework to call the deployed API Gateway API and supply the appropriate token in the Authorization header.
Related
I have created a new app client in Cognito, the tokens from the default app client are marked as valid by the API Gateway but not the token from the new App Client.
The API Gateway responds with HTTP 401 - UnAuthorized.
This should work because both the app clients have full permissions to the underlying users stored in Cognito.
I couldn't find any relevant documents explaining this discrepancy.
So, I was linking my AWS User pool to Amazon Alexa Smart Home Skill using this blog https://aws.amazon.com/blogs/compute/amazon-cognito-for-alexa-skills-user-management/.
On successfully linking the skill, Alexa would only send the accessToken in the subsequent API's.
The AWS API Gateway authorizers only check for the ID token and will deem the request invalid if it is given an AccessToken.
Thus, the requests were failing. It has nothing to do with default or non-default app clients.
Using a Cognito custom authorizer seems the best option, will disable API Gateway authorization.
I've managed to setup a third party google login by integrating it with Cognito user pools. On successful sign-on, I am able to access an id_token as a query parameter in the redirect url.
I'm trying to sign REST calls to API gateway using this id_token. I have an authorizer configured on that particular API using Cognito user pools. When I try to test this on the Authorizer UI by setting the Authorization(header) field to this id_token which I received as a query parameter, I keep getting an Unauthorized request error.
Also, I have configured an IAM policy for my user according to this doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-user-pool-authorizer-permissions.html
Can someone help me with what I'm doing wrong?
Thanks
Turns out you have to pass the access_token that Cognito returns as part of the authorization header. You can try if your access token works by testing it in the UI offered by the Authorizor interface of API Gateway.
I have a lambda function running behind the aws api gateway, that acts as the backend for my website. It uses a cognito authorizer to authenticate the users of my website. This works fine.
Now I need to authenticate a c# backend service against the api that is not running in the cloud has no user interaction. It should just synchronize data.
My initial plan was to configure cognito credentials and log into the cloud via the cognito sdk but this is not possible as the app would then need developer access to my cloud.
I also thought about using the api gateway api keys but I would still need the cognito authentication then.
So how can I authenticate my c# service against my aws api without user interaction being nessecary?
You could use Cognito User Pool Authentication.
This is an OpenID implementation where Cognito issues JSON Web Tokens (JWTs) where the signature of a JWT can be verified with a public endpoint.
In the context of API Gateway, you would use a Lambda as a custom authorizer, but the tokens could be verified in any environment/language with a relevant JWT Library.
More reading: Verifying a JWT issued by Cognito
I'm trying to setup security on an API using Cognito user pools. I'm getting back 401 Unauthorized.
The API and User Pools are existing, and I've been using the user pool to log into an application. I'm now trying to secure the API calls.
I created an authorizer on the API,
Then I added the authorizer to one GET method in the API
Then finally I tried to test the API in Postman. I'm using the AWS Signature authorization.
Calling the method returns 401. The method functioned before with no security, and turning off the authorizer makes it work again (without security).
Any ideas what step I'm missing?
The AWS Signature authorization is different than a Custom Authorizer.
The AWS Signature authorization (Postman) requests an AWS AccessKey and SecretKey to authenticate requests. This corresponds to IAM Authentication in API Gateway. The AccessKey and SecretKey are received through IAM.
A Custom Authorizer takes a JWT called #id_token that is issued by your specified Cognito User Pool. To test the validity of the token, go to your custom authorizer and click test, and then copy and paste the token into the text area.
The way to perform the Custom Authorizer authentication is this:
obtain an #id_token from the your user pool by following AWS Configuration
Configure API gateway with a Cognito custom Authorizer with your user pool as the source (Seems that you have done correctly)
Use OAuth 2.0 as Authorization in postman, with your #id_token as the Access Token, Or add the header: Authorization with the value Bearer and the #id_token
Drop a comment if you want me to add the AWS Signature Auth Flow.
For authorization using Postman when using Cognito user pools, chose No Auth. Then add a header Authorization (the value in token source field of your authorizer) and copy the id_token into that header value. I did not have to add anything else besides that to make it work (i.e. no bearer).
I'm using AWS Gateway as my web API with AWS Lambda as my serverless backend. Lambda functions are only invoked by my Gateway APIs. Through Lambda I call and execute operations on other AWS Services (RDS, SNS, etc.).
I want only my clients to get access to my web APIs. To do so I setup all of my Gateway APIs with AWS_IAM authorization. An unauthenticated client have only policies that let him invoke e.g. the function for login/sign up a user. In comparison an authenticated client have policies that enables him to access more recourses.
The question now is: Because I only want my clients to get access to my Gateway APIs and to do it as secure as possible, is it necessary to create a custom authorizer which checks the validity of tokens?
Neither I did setup a cognito user pool, nor I did setup a external public provider (google, Facebook, openId, amazon, etc.). I'm working with custom developer authenticated identities. All users are saved in AWS RDS. When a user tries to login and gets correctly authenticated through his email and password a open id and a jwt token is returned to the client. This is done by invoking 'getOpenIdTokenForDeveloperIdentity'.
I found some recourses on the web where people created a custom authorizer, but they did always verify the validity of the token by a external provider (google, facebook, auth0, etc.). This member did wrote that you only need to have a external provider when you have "[...]some totally different auth logic[...]" https://stackoverflow.com/a/39407156/5181862. And I don't think this is the case here.
The clients that run the application are iOS and later Android devices, if this information is necessary.
If all the APIs have AWS_IAM authorization, that is already pretty secure. AWS_IAM requires that the client have valid AWS credentials from the same account as the API (your account).
It sounds like you are using Cognito (talking about unauthenticated client policy), in which case your authorization model is secure if implemented correctly.