Can we integrate AWS cognito to authenticate API calls to our back-end? I was planning to use cognito access token which would be given to a reverse proxy server to create a JWT by value for back-end micro services. But I could not find any method to check the AWS token for validity. Any suggestions?
Thanks :)
Amazon Cognito was not designed to secure developer built APIs and I would caution you from using only the Amazon Cognito token to secure your API.
That being said, the vended Amazon Cognito token is a normal JWT signed using asymmetric encryption. This thread on the AWS forums has some example code in C# that another customer was able to use to verify the token.
Update 2015-07-09 AWS has announced Amazon API Gateway. Using API Gateway you can build a REST interface to your existing API (or to AWS Lamdba functions) secured with credentials retrieved via an Amazon Cognito authflow. See this blog post for additional announcement details.
You can retrieve the JWT tokens after authenticating users using Cognito. Pass the Access or ID token (depending on usecase) to your backend app and decode the token using any standard JWT decoder libraries.
Here is an article with sample code for reference explaining the process.
Related
I have an AWS REST API Gateway with Cognito authentication using the client credentials grant.
We have been creating new clients by hand and sharing the ID/secret with people who need to use our API. They send the ID/secret and "grant_type=client_credentials" to Cognito, it gives them a bearer token and they use the API with the token. All fine so far. (It is a CLI tool running on a schedule, not accessed by a browser. I specifically need to avoid any sort of "go to the browser to login".)
Now, we have a new "island" of users who have a local OIDC (Azure AD) provider that can issue them a bearer token from a curl to an endpoint.
Is there a way to make Cognito accept those tokens??
I have tried federating Cognito with a different oidc provider (I don't have AD, but a different provider), getting myself a bearer token from it and sending it to the API GW, and I just get 401'ed. I don't know if there is something I'm doing wrong or if it's not possible.
(Things I might be doing wrong seems to be a long list! I need to create a client in the other provider and add it's ID/secret/URL to Cognito, that works. I used the same client ID/secret to generate my bearer token. But when I'm in client creds flow in Cognito, I need to set a custom scope. Do I need to add that scope to my initial request to the other provider (The API GW doesn't require a scope, it is just a mock endpoint at the moment in testing). The client_id= in the request is for the client in the other provider, not the Cognito client ID. Should I set it to the Cognito client ID?)
OR do I need to write a custom authenticator for the API GW to validate the token? (Decode JWT, Check : issuer is allowed and signature is valid.)
And not use Cognito at all for these other users.
(If it was an HTTP API, I think I can create a JWT authoriser and it does it all for me, but it isn't and there are some features on REST APIs not available on HTTP (like WAF))
Sorry it's a bit short on details. I could spend days copy/pasting all the configs from ID provider/Cognito but if it fundamentally won't work I wasted my time!
(After trying it, I think maybe federation only works for actual users with a browser based login flow, not clients with a CLI flow. I can't find anyone saying client credentials flow does work anyway!)
Cognito is using the authorization server role. So in all cases, the tokens returned to client applications will be issued by Cognito. These apps will never deal with Azure AD tokens. Multiple types of client can coexist together:
CLIENT CREDENTIALS GRANT
Clients who use this flow might represent B2B connections. The business partner must always get Cognito tokens directly, and no federation is used here.
AUTHORIZATION CODE GRANT
Browser clients will use this flow, and you can configure Cognito to implement authentication by making a second OIDC Connect redirect to Azure AD.
My blog post provides a walkthrough on how settings are configured. Cognito will act as a client of Azure AD and use a scope such as openid profile email.
After a user login, Cognito will receive Azure AD tokens, validate them, then issue its own tokens. Nothing will change in the API gateway, which will continue to verify Cognito tokens.
In our project we are using API Gateway to get authenticated by Cognito User Pool.
Now, we are checking instead of hiting API Gateway can we directly hit Cognito for authenticating users.
So, wanted to check if there is any API of AWS cognito-idp admin-initiate-auth to get the tokens without using the CLI command?
Please refer to the link here. You will also find more information about using this API in one of the language-specific AWS SDKs.
For a complete list of all Amazon Cognito API references, refer here
Today, we use SFCC for e-commerce and it has also acted as our primary identity provider. We're in the process of migrating users and transitioning to use an external identity provider, Amazon Cognito.
After the migration, our hope was that we would be able to perform authentication using the external idp (Cognito) and use the issued Cognito 'Bearer' tokens to call the shop API.
Is this possible? Or, does the shop API require a JWT issued by SFCC?
I've not done it before, but there's a relatively new way to authenticate customers from a 'trusted system'. You can find more information about that here: https://documentation.b2c.commercecloud.salesforce.com/DOC2/index.jsp?topic=%2Fcom.demandware.dochelp%2FOCAPI%2Fcurrent%2Fusage%2FJWT.html
If your client application manages your customer credentials, it can obtain a JWT for a registered customer using the /customers/auth/trustedsystem resource. Because this API uses an OAuth token to identify the client application, we strongly recommend that you only use it in a system-to-system integration, where the client application keeps its own OAuth token secret.
After you are able to authenticate the customer you could use the Session Bridge functionality to convert that JWT to a session cookie.
Good luck!
Searching through the Internet, I have seen that EKS only enables IAM authentication for IAM users.
Is it possible to configure client certificate authentication manually? I mean, create Kubernetes users and roles internally and not use IAM authentication.
Kubernetes supports several authentication modules, for example:
X509 client certificates
Service account tokens
OpenID Connect tokens
Webhook token authentication
Authenticating proxy, etc.
You can find more details regarding them in the official documentation.
However, Amazon EKS uses only one specific authentication method, an implementation of a webhook token authentication to authenticate Kube API requests. This webhook service is implemented by an open source tool called AWS IAM Authenticator, which has both client and server sides.
In short, the client sends a token (which includes the AWS IAM identity—user or role—making the API call) which is verified on the server-side by the webhook service.
So the answer to your question is: if you choose to use EKS you only have one authentication option which is IAM.
I hope it helps.
I am attempting to authenticate a REST API in AWS API Gateway, which is protected by AWS Cognito through the command line to do some security testing of the API. So, i'm supposed to send the authentication token to get an answer, except i just can't figure out how to get that token!
Our Cognito User Pool is configured for Authorisation Code Grant Flow and Implicit Grant, but not for Client Credentials. Everything I found out during my research was about Client Credentials, so if anyone had a command line that actually works with these parameters it would be really nice!
If you have a REST API in AWS API Gateway that has Cognito Authentication enabled, you would need to pass the JWT Token generated by Cognito in the HTTP Request Header. To retrieve the JWT Token, you could either try a login operation from the Cognito Hosted UI, or you could alternatively try the AWS provided InitiateAuth or AdminInitiateAuth API calls. To give further clarity, if you select the Implicit Grant Flow, you get only an ID Token and an Access Token back. However, if you select the Authorization Code Grant Flow, you get a code back, which you could convert to JWT Tokens while leveraging Cognito's TOKEN Endpoint. An example for the AdminInitiateAuth API call(via the AWS CLI) as stated in the AWS Cognito Documentation is given as follows:
aws cognito-idp admin-initiate-auth --user-pool-id us-west-2_aaaaaaaaa --client-id 3n4b5urk1ft4fl3mg5e62d9ado --auth-flow ADMIN_NO_SRP_AUTH --auth-parameters USERNAME=jane#example.com,PASSWORD=password
These API calls/the Hosted UI Authentication Mechanism would give you an OIDC compliant ID Token and an Access Token after you login successfully. After you retrieve the Token, you could pass the token to the Token Source that you have set-up while creating the REST API Authorizer in AWS API Gateway. To know more about passing a certain parameter to a cURL request header, you could have a look at this StackOverflow question.