I'm using an AWS IAM secured AWS API Gateway in conjunction with AWS Cognito Identity Pool, similar to the Enhanced Simplified Flow described by AWS with an external (OpenId) Login Provider.
Retrieving the credentials is done by:
redirect to the Login Provider and obtaining the Id-Token upon successful user authentication,
authorize by AWS Cognito Identity Pool and assign an authenticated IAM Role,
receive the credentials (accessKeyId, secretKey, sessionToken) and
access all AWS IAM secured api endpoints with these credentials in an aws-signed request is working fine.
The problem is in the logout process:
How can I ensure, that upon logging out the user, the credentials received by the above mentioned process are properly and promptly not usable anymore to access the AWS IAM secured endpoints?
I don't see anything related to that in the documentation and to just wait for the credentials to expire is just NOT an option and a quite severe security problem:
Logging out a user has to prevent user's access to the API-Gateway right away!
Thanks for your help!
We are running into the same set of problems as yours and the AWS Team told us that it is not possible to revoke the tokens immediately after signout/globalSignout. In simple words, signout only invalidates the tokens to prevent uses in Cognito only, other services like API GW or S3 there they check for the expiration of the token in token itself rather than pinging the Cognito for user state verification. Let me know if you managed to solve it!
Related
I have two services, sitting in two separate regions on their own, that have the same authentification solution, with AWS Cognito and each of those instances has federated in their user pool, the same identity provider.
In front of the application, there is an API Gateway, that should grant access to the desired service.
The user could have the following scenario: goes to authenticate in region1, gets his token, and then the API Gateway from region1 will permit his access based on it. Can this token be used to access a service in region2?
Assuming Cognito is configured in region1, if you set the Cognito pool from region1 as authorizer for the API Gateway in region2, that should allow this API Gateway to authenticate users in Cognito. It also works cross-account.
Hopefully the docs help: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-enable-cognito-user-pool.html
I am currently investigating the use of Federated Identities and from the many examples I have read, it seems to be a way to grant users temporary credentials to various AWS services. For my case, the API Gateway is all that the user will interact with, since the API server is the one making calls to other services like S3 and DynamoDB. I like how permissions are controlled using IAM, but I'm failing to see any other appeals of Federated Identities. User Pools itself already supports password/fb/google/etc sign in, the only downside I see with user pools is that I'll need to do the authorization manually in the API layer. Is there something else I am missing with Federated Identities? Is it worth it given my use of only API Gateways (externally).
It all depends on the way that you will secure your API Gateway endpoint.
If you secure your API using AWS IAM, you'll need a way to convert your authentication tokens in AWS IAM Roles. For that scenario you can use AWS Cognito Idp (not the User Pool) or AWS Federated Identities. The difference is: using AWS IAM Federated Identities you will need to call AWS STS AssumeRoleWithWebIdentity in your frontend code. If you use AWS Cognito Idp this is done for you. . (AWS strongly suggest that you use the Cognito Idp in that scenario)
If you secure your API using AWS Cognito User Pools you don't need to use AWS Federated Identities. You can connect API Gateway directly to AWS Cognito and the service will enforce the controls for you. In that case you'll need to have a Cognito User Pool.
You also have a choice to use Custom Authorizers. In that scenario you will implement a lambda function that will evaluate your request and decide if it is authorized or not. In the same way, you won't need federated identities.
And finally you have the API Key authorization, that you already mentioned that is not applicable to your use case.
I'm not clear on how to send credentials and IAM access to an API gateway. This seems clear:
There is the tutorial on AWS but this is not the way I wanted to access my API.
API Gateway example
As most would know, you put your AWS Key and Secret key in a configuration file that lives in .AWS on the userspace of the user but if you are using a website, for example, you won't have that. Is the idea that anytime a user access the API that you put that user in an anonymous group that has access to the .credentials file?
You are describing IAM authentication for API Gateways. For your of your web app to generate IAM credentials I would recommend using a Cognito Identity Pool Authenticated Role. The Cognito Identity Pool Authenticated Role Exchanges a JWT for the AWS IAM credentialsthat are used in API calls. Your users will first authenticate against the identity pool. The identity pool even allows for unauthenticated users that are using your registered app to generate credentials with permissions which you specify. This guide will show you how to generate these credentials in your code.
Alternatively you can use API Gateway Identity Pool Authorizer or API Gateway Lambda Authorizer to secure your API.
We're building an application using AWS App Sync, we're still in a very early stage.
Our application has a restricted area, through user sign-in, which is being managed via aws cognito users pool. And this is fine.
We're having issues on the public area which doesn't require any authentication.
How can we protect these public endpoints?
We're having some doubts about hard coding the api key (that we know can be rotated), is it a good practice (documentation page says that it isn't ideal for production)?
Is there any way to authorise the origin? (aka, any request coming from www.foobar.baz is ok)
I would suggest using Amazon Cognito Federated Identity to control authenticated and unauthenticated access to the api. In order to do use Amazon Cognito Federated Identity with AWS AppSync, you need to use AWS IAM based authorization.
For the authenticated access you can use Amazon Cognito User Pools and federated to Amazon Cognito Federated Identity and since the federated identity can also allow for unauthenticated users it will allow you to control some api's which can be made public via an IAM policy.
For more information please read the AWS IAM Section of our security guide here
Under your AppSync app's Settings menu, where you set the User Pool Configuration, there is an option to set a default action. You can change this to DENY and all unauthenticated requests will be rejected. The alternative approach is to ALLOW everything, and manually add #aws_auth directives to every query/mutation/subscription field that you care about restricting.
I am building web application based on microservice architecture. At this moment I am considering few ways of user authentication flow. I predict following, example user roles:
admin - is able to create content, upload files etc (admin account can be created only by another admin)
unauthorized user - can view content
authorized user - can comment content
Here is, how I was thinking about authentication flow so far:
authentication service - have access to DB with users credentials and permissions
api gateway - retrieve requests from user, check if user is logged in (ie verifies OAuth2 access token with auth service) and transfer flow to other services based on user request (attaching JWT token with some basic user info)
another service - accept only requests from api gateway, and trusts user data from JWT token (does not need to connect with auth service to get information about user).
After deploying some stuff on AWS infrastructure my way of thinking have changed a little bit. As far as I understand AWS products (Lambda - serverless applications and API gateway), I should implement authentication flow as follows:
authentication service - gets request from user, retrieve data from dynamoDB and provide user cookie with JWT signed by private key
any other service - retrieves request with JWT token, verifies signature using public key, and perform some action.
And now the question comes:
How deos AWS Cognito fits here? Is it something useful for me? As far as I understand, Cognito simplifies flow of authenticating users via 3rd parties (facebook, twitter etc. etc.). Does AWS Cognito serves login page, separated from my application, or it is only background/webservices impelementation?
So far I am thinking about Cognito as a replacement for my authentication service - any of my services, should impelemnt Cognito authentication flow provided by SDK from amazon, and my static website would implement JavaScript SDK for user login/register. Am I right?
First of all AWS Cognito consists of two services.
AWS Cognito UserPools (Which is the Identity Provider) - This is the service where you can create the users and manage their credentials with other policies. It can also provide the login screen where we can customize the logo and look and feel so that it can become a plug and play Login service. Then it is also possible to configure the authentication flow (For example to make the service as an OpenIDConnect authentication provider so that it will return a JWT token once user logs in). It is also possible to connect Social Identities (Facebook, Google & etc.) and SAML.
AWS Cognito Federated Identities (Identity Federation to grant users access AWS Services) - This service is capable of accepting AWS Cognito UserPool Token or direct access from other providers where we can federate the access to AWS resources. For example, AWS Cognito Federated Identities can grant temporal access to a User, Authenticated from another provider (e.g; AWS Cognito UserPools) to upload files to S3.
For more details refer the article The Difference Between AWS Cognito UserPools and Federated Identities?.
So coming back to your questions,
So far I am thinking about Cognito as a replacement for my
authentication service?
you can use AWS Cognito UserPools authentication service to issue JWT tokens and validate the token in AWS Lambda Custom Authorizer at your other service endpoints. This is also the place where you can do Authorization.
My static website would implement JavaScript SDK for user
login/register. Am I right?
Not necessarily. If you use AWS Cognito UserPools Hosted UI, you will get Login, Signup, Password Change, Confirmation pages, by default along with auto redirection for Federated Identities (Based on the configurations) such as Facebook, Google or Corporate Credentials like Office365. Although the customization is limited, you should be able to add your own logo and change the background color of these screens. If you plan to implement this by your self, then you can use AWS SDKs to implement these screens.
For more details on the serverless architecture refer Full Stack Serverless Web Apps with AWS.