I am attempting to allow a third party app (Google Home) to access information from a AWS Cognito User Pool.
The flow of the entire process is as follows (assuming I understand it correctly that is):
The user tries to link their devices (which are all managed inside various AWS services) to Google Home.
The user is then redirected to our oauth2 page where they log into their account in the cognito user pool
They succesfully log in and are provided with an oauth token
The Google Home app can then use that token to send requests to our back end, allowing them to control their devices, but not the devices belonging to other users.
I am not exactly sure how to setup the cognito user pool as an oauth2 provider. I can find lots of info going the other way (for instance using Google to sign into our AWS user pool using federated identities) but that doesn't solve our problem.
Any help or direction would be greatly appreciated.
Thanks in advance
Amazon Cognito now supports OAuth 2.0. Login to the Amazon Cognito Console and follow these steps for an existing user pool:
Create a domain in the "App Integration" section.
In the same navigation go to "App Client Settings" and enable the providers you want enabled on the client, in your case Cognito. Also add the allowed callback and logout URIs as well as the allowed OAuth flows and scopes.
Now your authorize endpoint is https://.auth..amazoncognito.com/authorize?client_id=&redirect_uri=&response_type= and same way you can find the token endpoint.
More details...
Related
I deployed AWS application load balancer to route requests to my backend service. And I'd like to add authenticate on it via cognito basic username and password.
I have read this doc https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html and it only mentions about OIDC, SAML, LDAP etc. How can I use username/password to authenticate ALB?
The ALB itself provides direct integration with Cognito as an authenticator.
First, you need a Cognito User Pool. Within it, you need to create an App Client. This will then be used by the ALB when it uses OpenID Connect as a relying party in order to authenticate users against Cognito using the Authorization Code Flow.
So, for every route in your listener rules, you can add an "Authenticate using Cognito" step, where you then select your Cognito User Pool and the App Client Id.
After that, every request for this listener rule will first redirect the user to the Cognito login page.
Since Cognito itself can also federate authentication to other Identity Proviers, such as Facebook, Google, etc., this is also an option. But if you only want username/password authentication, then Cognito already gives this as an option for users in your user pool.
Basically, all the steps are explained in your mentioned AWS documentation page.
What I have done so far?
I have integrated Microsoft AD with AWS Cognito by adding Trust relationships and setting Cognito Identity provider. In this, I have set up an app domain prefix during Cognito set up. By using the following URL I am able to receive the token by logging in the AD login page. So when I decode this token I getting the required attributes and other information.
What I actually want?
So I don't want my users to be redirected to the AD login page and later to the application. I need just a REST API where I can provide the AD user credentials and this API will return the above JWT token which has all the information.
So in short, I want to get the Cognito JWT token by using the AD user credentials. These users are the part of AD groups which are linked to the AWS IAM by adding trust relationship using ADFS. So is there a way in which I don't need to use the Cognito hosted UI. Instead, my users will hit one API and get the credentials. I don't know what this API is.
Any help will be appreciated.
I am in the same dilemma myself, but I've found a very useful question (with answers) that might help you out.
It's been some time but maybe this will be useful for new people having the same problem nowadays.
What is the REST (or CLI) API for logging in to Amazon Cognito user pools
I think you'd want to enable the ClientCredentials flow in your cognito user pool.
You can read more on this flow here https://aws.amazon.com/blogs/mobile/understanding-amazon-cognito-user-pool-oauth-2-0-grants/ to make sure it is what you need (oauth flows and grants are the same thing).
I searched all over, tutorials, web, everybody jumps away without explaining(I understand why) the checkboxes in app client settings:
Enable sign-in API for server-based authentication
Only allow Custom Authentication
Enable username-password (non-SRP) flow for app-based authentication
The learn more link does not help me, lots of information and not so easy to understand, grasp. Can someone explain this settings?
Here is my take on the matter.
App client has several Auth Flow Configurations.
1. Enable username password auth for admin APIs for authentication (ALLOW_ADMIN_USER_PASSWORD_AUTH)
This enables Server-Side Authentication Flow. If you don't have an end-user app, but instead you're using a secure back end or server-side app.
2. Enable lambda trigger-based custom authentication (ALLOW_CUSTOM_AUTH)
This enables the Custom Authentication Flow. This can help you create a challenge/response-based authentication model using AWS Lambda triggers.
https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-challenge.html
Under User Pools -> Triggers you can see many lambda functions. You can use Create Auth Challenge, Define Auth Challenge and Verify Auth Challenge Response functions to create a custom authentication flow.
3. Enable username password based authentication (ALLOW_USER_PASSWORD_AUTH)
This enables Client Side Authentication Flow that uses user password-based authentication. In this flow, Cognito receives the password in the request.
You can use AWS Mobile SDK for Android, AWS Mobile SDK for iOS, or AWS SDK for JavaScript to implement this.
4. Enable SRP (secure remote password) protocol based authentication (ALLOW_USER_SRP_AUTH)
This is similar to the above flow in section 3. except for the password verification. This flow uses the SRP protocol to verify passwords.
http://srp.stanford.edu/whatisit.html
https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UserPoolClientType.html
5. Enable refresh token based authentication (ALLOW_REFRESH_TOKEN_AUTH)
After successful authentication, Amazon Cognito returns user pool tokens(Three tokens) to your app. You can use the tokens to grant your users access to your own server-side resources, or to the Amazon API Gateway. Or, you can exchange them for temporary AWS credentials to access other AWS services.
The three tokens are ID Token(JWT), Access Token, Refresh Token. The refresh token can be used to retrieve new ID and access tokens. Once you login to a mobile app, you are not needed to log in each time when you close and open the application and this functionality is implemented using refresh tokens.
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html
What about Amazon Cognito hosted UI ?
App clients can be configured to use built-in Cognito webpages for signing up and signing in users. When using the hosted UI you can enable both the Authorization code grant and the Implicit code grant, and then use each grant as needed.
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-app-idp-settings.html
Here is my attempt at explaining these options. Before that I would like to briefly mention about Oauth2, which is the protocol on which AWS Cognito is based.
In the context of AWS Cognito, Cognito itself is the Authentication (OAuth) server and also the Resource server (because we create users in Cognito user pool) and your app would be the Client (which sends the authentication request). The client has to first register itself with the OAuth server - this is what is being done in the "App clients" section of Cognito.
The recommended OAuth2 flow is Authorization Code Grant flow. In this flow,
i) The Client sends username/password to the OAuth Server.
ii) The OAuth server validates and calls back the client with a
authorization code.
iii) The Client again sends this code back to the OAuth server
iv) The OAuth server sends the tokens to the Client.
Please read the above linked article for more explanation on OAuth2.
Now explaining the options in Cognito App Client settings:
1. Enable sign-in API for server-based authentication
With this option, your client app can directly receive the tokens without having the additional step of first getting the authorization code.
There are Cognito APIs like AdminInitiateAuth, Admin-* which does this. However, these APIs require AWS admin credentials. Hence usually these calls are done by the backend server of the client app. The front-end can pass the username/password to the backend and the backend server can communicate with AWS Cognito and authorize the user.
2. Only allow Custom Authentication
Here you don't use the OAuth provided authorization code grant flow. Instead, you can define your own steps and challenges. Your client app can ask a secret question etc, before authenticating and giving tokens.
3. Enable username-password (non-SRP) flow for app-based authentication
This is the least safe flow. This skips the part of returning the authorization code and directly returns the tokens back to the client.
I hope this explains.
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.
I am planning to write a mobile app with AWS handling the backend work. Like many common apps, mine will support user registration and login. All backend resources should be secure based on the user's role.
After reading AWS Cognito, it handles both Open authentication provider and Developer Authentication provider. This helps to support third party login. The capacity of syncing data is a big plus.
However, I have some questions about Cognito when I try further implementation.
What are the user credentials stored?
I need to add more user attributes (eg. email, profile image etc.) when a new user is created. Can Cognito handle this? Or do I need to use storage like S3 to store the entire user profile?
Does Cognito support email verification for user registration?
Does Cognito handle 'forgot password' feature?
All advices are welcomed.
There is now Amazon Cognito User Pools (currently in beta), allowing to store user credentials, see here
Update: Cognito has since added a new feature that does allow storing credentials. See Cognito User Pools for more information.
Amazon Cognito does not store credentials. Instead, it allows you to offload the task of securely storing credentials to any OpenID Connect-complaint credential provider such as, but not limited to, Facebook, Google, and Login With Amazon.
If you have a credential provider that is not OpenID Connect compliant, you can use the Developer Authenticated Identities capability to leverage another authentication system as a credential store (such as your own back-end service). Registration, email verification, and forgot password features would be handled by the Identity Provider: Either an OpenID Connect provider (e.g. Facebook) or your own provider via Developer Authenticated Identities.
Cognito's Sync capability gives you the ability to store profile information or any other information specific to the current user (referred to as "identity" in Cognito). There is a good blog post about using Cognito Sync to store & synchronize data here.