We are looking to move to Cognito for user authentication. Currently we rely on our system to create the user and authenticate using JWT tokens generated internally. We also have a guest user role where anonymous users are given access to limited apis. To achieve this, we first create the guest user as a normal user in our system and mark it a guest in db. This way we can generate JWT tokens for guest users that can be used to authorize limited set of apis.
With Cognito, creating authenticated users is straightforward as userpool token (ID token) generated can be used in Api Gateway with Cognito authorizer. However, we are looking to implement guest user access as well via Cognito. Userpools does not have that support. The only option seems available is Cognito Identity pool for unauthenticated access. But this requires IAM credentials to be generated and passed to Api Gateway which is different than ID Token flow for authenticated users. Also, it does not mention how we can attach custom information to the identity (guest) so that it can be decoded at the authorizer level in Api Gateway and passed to backend service.
Is Identity pool the only approach to implement guest access? My usecase does not require access to any AWS resources except Api Gateway for guest users. Please note the Api Gateway apis used for guest users are also being used for authenticated users.
Related
Currently I'm developing serverless architecture where there are set of resources and methods in AWS API gateway. I plan to add Cognito authentication(user pool) and authorization as secure layer to AWS API gateway.
There are 3 authorizer in AWS API Gateway which are IAM, Cognito User Pool and custom lambda.
For my use case, the sign-in and sign-up(authentication) are using cognito user pool via API gateway. It's perfect works. My user will given app client id and client secret to enable both processes. Once after sign-in, my intention is get user able to use the access token(returned by user pool) to access resource via api gateway.
However, my user can has different role such admin, owner or guest. User only can access the authorized api. My approach is to put user into different group in user pool, assign IAM policy to group and enable identity pool. This force me to change the authorization type in api gateway to IAM. and IAM require every request to be signed by Signature V4.
It means every requests have to sign up by session token, access key, secret (returned after exchange id token with federated pool) instead of using access token based approach. So in my use case, after my user sign-in via api gateway, my client app(web/mobile/postman tool) has to generate signature and put in Authorization header. Is there alternative ways to control authorisation in user pool group but using access token in api gateway? My understanding is access token (in Authorization header) is much easier to use than complex signed signature process.
Correct me if I'm wrong. Thanks.
Will this help instead?
Create groups in user pool and assign IAM role to the group.
And then add users to the group.
More documentation here: https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-user-groups.html
You are on the right track but you have chosen one of the paths of Authorizing the user requests on AWS. You are using IAM and Identity Pool and because of that, you are forced to sign every request using Signature V4 provided by AWS.
Instead of going for I would suggest as per my experience to choose custom Lambda Authorizer over Identity Pool. In this case, your authentication will remain as it is that you have already built. But instead of applying IAM as Authorizer in API gateway, you can create a lambda function that will receive the ARN of the API gateway that the user wanted to authorize in the request and user ID_TOKEN that you received in during authentication from User Pool.
{
...
"cognito:roles": [
"arn:aws:iam::**********:role/addBookSellerRole"
],
"exp": 1565758916,
"iat": 1565755316,
...
}
You can see you will get the roles array from the ID_TOKEN in JWT received from authentication. You can use this role to fetch the attached policies to this role. Follow this document to fetch the policies from the role.
Once you get the policy JSON you can compare it with the ARN of the method received in request with the list of policies. And this way you have to generate a Policy Document that will either Allow or Deny the request.
To read more about it visit my medium blog Authorization using Cognito + API Gateway + IAM.
I'm trying to figure out how to use the Azure Graph API to query a user's full name (first and last) from a given username. I understand I can do this with the following Graph API call...
https://graph.windows.net/myorganization/users/{user_id}?api-version
However, I am not sure how I go about getting an access token to use with this, because this process will be called without a user logging in, which is usually how we obtain an access token.
Is there anyway I can pass a username/password to a given URL using cURL or something and obtain an access token that way, so it is done behind-the-scenes?
There are two main authentication methods which are supported by OAuth 2:
Authorization Code Grant Flow
Client Credentials Grant Flow
The first flow requires a user agent to be present to sign into the client service and results in a delegated token. The second method does not require a user to sign in, as it only authenticates using the client secret; this results in an app only token.
If you want to create a background service that captures data from the AAD Graph API, you can absolutely do this using the Client Credentials Grant Flow, which does not require a user to be present at any point during the authentication flow.
You simply need to configure your application to to have app only scopes. Read here: Permission scopes | Graph API concepts. App only scopes all require tenant administrators to consent to the application in order to get access to data.
Finally, I feel I must mention that there is another less used flow specified in the OAuth 2 spec: Resource Owner Password Credentials Grant. This flow specifies how a client application who has knowledge of a user's username and password could directly pass those parameters and get an access token on behalf of the user. However using this flow is not good practice at all.
The resource owner password credentials grant type is suitable in
cases where the resource owner has a trust relationship with the
client, such as the device operating system or a highly privileged
application. The authorization server should take special care when
enabling this grant type and only allow it when other flows are not
viable.
We support this in our V1 endpoint, but not in our new V2 endpoint. You can read this blog to learn more.
I am working on a web app where users can login/signup with their personal email addresses or login with federated identities like Facebook/Twitter. I have set up Cognito User pool and identity pool for the same.
After successful login , APIs hosted on API gateway would be invoked to display some data on the application. I would like to implement authorization for every API invoke call and return the response only for authorized users.
I have created User Pool Authorizer in API Gateway and I am able to authenticate users created in userpool based on the Id Token.
As per my understanding , to authenticate users from Identity pool , I can use AWS_IAM in Api Gateway. AWS_IAM may not be right solution for my application as API can be invoked by user in userpool as well as identity pool.
I am thinking of implementing authentication using Custom Authorizer using Lambda functions.
If custom Authorizer has to be implemented , should validating policy document based on the session token be sufficient to validate the users from both Userpool/Identity Pool? Kindly suggest alternatives for custom authorization,if any.
Thanks in advance
Have you seen this blog post? https://aws.amazon.com/blogs/mobile/integrating-amazon-cognito-user-pools-with-api-gateway/
It's possible to directly integrate your Cognito user pools tokens as an authorizer for API Gateway, and it simplifies the flow you described greatly.
I established a authentication flow with Facebook Login and AWS Cognito on the client site. Works fine. But now I need a reference of the user with its facebook id in a dynambodb table. Of course I could just call a AWS lambda function exposed via AWS API gateway, but how can I verify that the API call actually has a valid facebook id and that this facebook id matches the AWS Cognito Id. Maybe I am missing something here, I hope you guys can point me in the right direction ;) thanks!
If you can key your ddb table by cognito id instead of facebook id, you can invoke api gateway with cognito credentials. If you use callee credentials when calling lambda you can access the cognito id via the token $context.identity.cognitoIdentityId. This ensures the call was made by the owner of this id. You can further check that $context.identity.cognitoAuthenticationProvider is graph.facebook.com to ensure they authed via Facebook. Unfortunately, the facebook id is not passed in the credentials, so if you need it you will need a lookup table mapping cognito id to facebook id. For more details on the available tokens see here.
I would suggest to do the following (I'm new to AWS as well, Let me know if you have any suggestions):
Create a API Gateway /fblogin endpoint where you will POST the Facebook Access Token (You will authenticate with Facebook on the client side to get this token). That endpoint is linked to a Lambda function say fb_login.
In fb_login function you will authenticate with Amazon Cognito to get its credentials. You should have created a Federated Identity user pool in Cognito and assign appropriate roles to assume for this user pool. This helps if you want to restrict your API only to those who are authenticated and authorized. So, the result from Cognito will have IdentityId and Credentials. You can return them as a result of your request to /fblogin.
Using the above result you can sign the requests you send to your API on API Gateway (Or you can use AWS custom generated SDK for your API to handle the signing). On the API Gateway endpoints, enable CORS and authentication as AWS_IAM. This way, API Gateway verifies the user automatically by checking the signature in the request. You can get the User Id from $context.identity.cognitoIdentityId as others suggested. This way, you can be sure that the user is authorized and authenticated.
Note: Make sure you implement /fblogin endpoint on HTTPS, then the FB Access token will be secure. If not, it will be visible as plain text over HTTP.
Also, use a Dynamo DB table as a log for CognitoID - FacebookID. You can incorporate this in the Step 2 Lambda function ifself or anything you think is appropriate.
I have a scenario where a user has logged into to a web application (authenticated with OpenID Connect) and then needs to access data from a separate REST service.
The REST service needs to determine whether or not the user has permission to access the requested data, but if the user does have permission, then it should grant authorization to the web application without requiring the user to interact with the UI.
Essentially, what I need is a two-legged OAuth solution where the client/relying party is fully trusted but the user, who's already been authenticated, is not.
Going in, I assumed that OAuth could accommodate these requirements, but none of the grant types seem to match the requirements:
Authorization Code is the opposite of what I need, as the user is pretty much automatically trusted but the client is not, requiring that the user grant access to the client via a web form.
Client Credentials trusts the client (which is what I need) but does not give the service an opportunity to determine if the user has permission to the resource (user auth tokens are not passed to the service, making all requests essentially "anonymous").
ROPC (Resource Owner Password Credentials) would appear to be the only option, but requires the web application to know and possibly store the users' login credentials (which is untenable).
Is this a gap in OAuth? Or am I misunderstanding these grant types? If OAuth can't support this scenario, is there another widely adopted open standard that I've missed?
Of note: I only own/control the web application, while the customers (all of which are businesses) own/control both the authentication servers and the REST services. Therefore, a shared, non-proprietary standard is necessary so that our customers will know how to configure their services (IBM, Microsoft, whatever) and so that I'll know how to pass along any authentication tokens, etc.
I think this is possible using normal OAuth2 flows. You have your web application use the code authorization grant to get a token to call the API on behalf of the user.
Your web application makes the call to the API attaching the JWT token in the Authorization header. If the REST service determines the user does not have permission to access the resource, it returns a 401 Unauthorized HTTP response code.
Your web application handles the 401 response by going back to the authorization server and using the client credentials grant to get an access token to call the REST API on behalf of the client itself.
As both grants allow you to get a refresh token, you should be able to switch between access tokens easily.
If there is no trust relationship between the web application and the REST service, there's no way around using the Authorization Code grant since the user needs to be involved anyhow to allow the web application to make the call on behalf of the user.
If there is a trust relationship between web application and REST service you should be able to use the regular OpenID Connect flow to get an access token to the web application at login time that can also be used in calls towards the REST service.
You may pass on the user information as part of a JWT (i.e. a structured) access token that is signed by the web application itself or the OP; that would be OAuth 2.0 compliant. See https://www.rfc-editor.org/rfc/rfc6749#section-1.4 and May an OAuth 2.0 access token be a JWT?.