I have an Angular app which I want to secure using AWS Cognito. I initially started using the package angular-oauth2-oidc which worked great, I just gave it a few details (issuer, client_id etc) and was up and running.
I'm now looking at implementing Amplify but am finding the examples are doing much more than I want. The examples and quick start all involve creating resources which I don't want, I just want to redirect to the hosted UI and get a token on response.
Can I use Amplify just to handle the logging in (using hosted UI) and the token? I shouldn't need to create any new resources, my applications aren't hosted in AWS, I just want to use the authentication side of things.
Thanks
In the amplify documentation it states how to use the Amplify JS Framework with existing AWS ressources.
If you want to use your existing AWS resources with your app you will need to manually configure your app with your current credentials in your code, for example:
import Amplify from 'aws-amplify';
Amplify.configure({
Auth: {
// REQUIRED - Amazon Cognito Identity Pool ID
identityPoolId: 'XX-XXXX-X:XXXXXXXX-XXXX-1234-abcd-1234567890ab',
// REQUIRED - Amazon Cognito Region
region: 'XX-XXXX-X',
// OPTIONAL - Amazon Cognito User Pool ID
userPoolId: 'XX-XXXX-X_abcd1234',
// OPTIONAL - Amazon Cognito Web Client ID
userPoolWebClientId: 'XX-XXXX-X_abcd1234',
}
});
Related
I’m trying to connect a user pool in my AWS Cognito instance to Auth0 following the instructions in the How do I set up Auth0 as a SAML identity provider with an Amazon Cognito user pool? article.
When I click Debug from the Addon: SAML2 Web App section with the following settings…
Application Callback URL: https://{amazonCognitoDomain}.auth.{awsRegion}.amazoncognito.com/saml2/idpresponse
Settings
{
"audience": "urn:amazon:cognito:sp:{cognitopoolId}",
"mappings": {
"email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
},
"nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
}
… I’m taken to the following URL
https://{subDomain}.auth0.com/login?state={someState}&client={auth0ClientId}&protocol=samlp&response_type=code&redirect_uri=https%3A%2F%2Fmanage.auth0.com%2Ftester%2Fsamlp
Which gives me this:
Opening the console I can see the error reported is…
At least one email, sms or social connection needs to be available.
I’ve also tried saving the settings and continuing on with the instructions in the article but got this same error when testing from Cognito.
I have one database connection enabled (see below) under the application’s Connections tab (which should store the email) and both the social and sms options are disabled.
Any help is very much appreciated!!
You must configure an authentication source (a connection in Auth0).
You're configuring Cognito as a SAML SP and Auth0 as the IdP. Auth0 needs to be configured to authenticate users in some way.
If you are using your own database you need to ensure you are handling authentication through hooks (action scripts).
We're developing a website with AWS Amplify that uses Cognito to handle the authentication. I've configured the user pool in Cognito to use Keycloak as the OIDC IDP. The basics of logging in and out are all working as desired.
I now want to get more information back from Keycloak into the Amplify app. If I use https://openidconnect.net/ as a test point for authenticating to Keycloak as if it was Cognito, I can decode the JWT in https://jwt.io and see the additional information I'm after.
In Cognito, in General Settings > Attributes, I've added a custom attribute "groups":
In General settings > App clients, I've marked that attribute as readable:
Under Federation > Attribute mapping, I've mapped the OIDC attribute to the User pool attribute:
but, when I authenticate in the web application and dump the payloads for the ID and access tokens, I cannot see the "custom:groups" attribute.
What am I missing or misunderstanding here?
Thanks.
I am running an react app. I want to log error to my aws cloudwatch without hard coding the access key and secret key on my client side code. I am using 'Error Boundary Component' for catching error.
Thank you for your help.
I assume by "react app" you mean a React-based web application, often called an SPA for Single Page Application.
In that case you are correct, you do not want to hard-code and credentials as that would expose them to any user who has access to the page.
The most common architecture for doing this is to setup the following:
A Lambda that will take your logging event and log it for you in Cloudwatch.
An API-Gateway that your application can call that will trigger the Lambda.
An Authorizer on the API-Gateway resource that will validate a JWT that is passed from the application.
AWS Cognito that will supply your application with a JWT based on some login, either directly or via some integration with another service that is applicable for your case.
I have created a Github OAuth app and I am trying to add the app as an OIDC application to AWS Cognito.
However, I cannot find a proper overview about the endpoints and data to fill in anywhere in the Github Docs.
The following fields are required:
Issuer -> ?
Authorization endpoint => https://github.com/login/oauth/authorize (?)
Token endpoint => https://github.com/login/oauth/access_token (?)
Userinfo endpoint => https://api.github.com/user (?)
Jwks uri => ?
I couldn't find the Jwks uri anywhere. Any help would be highly appreciated.
Seems like there is no way to get this working out of the box.
https://github.com/TimothyJones/github-cognito-openid-wrapper seems to be a way to get this working.
If any Cognito dev sees this, please add Github/Gitlab/Bitbucket support.
GitLab 14.7 (January 2022) might help:
OpenID Connect support for GitLab CI/CD
Connecting GitLab CI/CD to cloud providers using environment variables works fine for many use cases.
However, it doesn’t scale well if you need advanced permissions management or would prefer a signed, short-lived, contextualized connection to your cloud provider.
GitLab 12.10 shipped initial support for JWT token-based connection (CI_JOB_JWT) to enable HashiCorp Vault users to safely retrieve secrets. That implementation was restricted to Vault, while the logic we built JWT upon opened up the possibility to connect to other providers as well.
In GitLab 14.7, we are introducing a CI_JOB_JWT_V2 environment variable that can be used to connect to AWS, GCP, Vault, and likely many other cloud services.
Please note that this is an alpha feature and not ready for production use. Your feedback is welcomed in this epic.
For AWS specifically, with the new CI_JOB_JWT_V2 variable, you can connect to AWS to retrieve secrets, or to deploy within your account. You can also manage access rights to your cluster using AWS IAM roles.
You can read more on setting up OIDC connection with AWS.
The new variable is automatically injected into your pipeline but is not backward compatible with the current CI_JOB_JWT.
Until GitLab 15.0, the CI_JOB_JWT will continue to work normally but this will change in a future release. We will notify you about the change in time.
The secrets stanza today uses the CI_JOB_JWT_V1 variable. If you use the secrets stanza, you don’t have to make any changes yet.
See Documentation and Issue.
I just successfully went through the Cognito setup through AWS console, which is a manual process. I wanted to code it up next, i.e.,
I wanted to setup and configure my Cognito with Cloudformation config file AWS AWS::Cognito::UserPool. However, I don't see a field that define the open id connect providers (i.e, the Facebook and Google as identity provider).
Is there a way to do so?
I am on the Cognito team and this is not possible at this point. However, it is on our roadmap to bring CloudFormation support up to speed to all the features we have launched recently.