Open amcdnl opened 5 years ago
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I agree, there is not clear documentation on how to integrate another Auth provider which is not Google, Facebook or Amazon
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Why is this stale?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Why is this stale?
Tried using the auth0 HOC out of the box with a manual configuration set-up! Doesn't work at all, and the docs are somewhat misleading.
@hyprstack - I finally got it working, heres what I ended up with on the frontend:
const auth = {
type: AWS_CUSTOM_CONFIG.aws_appsync_authenticationType as 'OPENID_CONNECT',
jwtToken: () => {
// This Auth class is my own custom class around Auth0 Client
const session = Auth.getStoredSession();
if (session) {
return session.idToken;
}
}
};
then later:
class Auth {
async cognitoSignIn() {
const authObj = Auth.getStoredSession();
if (authObj.idToken) {
const {
idToken,
expiresAt,
user: { name, email }
} = authObj;
try {
await AuthAmplify.federatedSignIn(
this.props.domain,
{
token: idToken,
expires_at: expiresAt
},
{
name,
email
}
);
} catch (e) {
console.log('Congnito Error', e);
}
}
}
}
@amcdnl What do you do in your own Auth class? Could you provide the full code of how you got it working? Have you tried using the withAuth0 HOC? I got a manual set-up working without any of the HOC, however lost all of the user details when running the appsync resolvers.
@amcdnl also created this issue. I have it partially working https://github.com/aws-amplify/docs/issues/973
Unfortunately it looks like this Auth0 documentation is now out of date with the UI for AWS:
https://auth0.com/docs/integrations/integrating-auth0-amazon-cognito-mobile-apps
This is the graphic it provides in the previous link when saying to create a new pool:
And this is the UI you're given when you go to create a new OpenID federated pool:
I have no idea what to put in those bottom additional 6 fields below the Client ID and Client Secret... Any one else figured this out recently?
@grimunit You need to configure a SPA on auth0 in order to get those values. Once you have them, then configuring your OIDC provider will not be hard. A lot of their docs regarding the OIDC provider is somewhat limited. More so if you are using Amplify on the client side.
Attributes request
method should be: POST
Authorize scope
should be: email profile openid
Issuer
should be the Domain value of your auth0 application (with the protocol https://)
The other values should be found in advanced settings, under the endpoints tab of you auth0 application.
@hyprstack awesome thanks that worked. I didn't realize those were the values you needed to put in, I already had them from my initial Auth0 integration setup. I feel like I'm most of the way there and have finished all of the steps in the Auth0/Cognito doc above... except for the part about the thumbprint. That part doesn't seem to make much sense and seems like others are also struggling with that part as mentioned in this issue: https://github.com/aws-amplify/amplify-cli/issues/177
But I'm still getting the following error:
I'm clearly now seeing that an ARN is trying to authenticate with Cognito:
I have the unauth role created and attached to the identity pool as well:
Here's my code that I've pieced together from the Amplify docs from the Auth/Vue sections:
async authenticateWithAwsCognito ({ idToken, user }) {
const { exp } = jwtDecode(idToken);
const refreshFunction = (token, exp) => {
return new Promise((resolve, reject) => {
const data = {
token, // the token from the provider
exp, // the timestamp when the token expires (in milliseconds)
};
resolve(data);
});
};
const authConfig = await Auth.configure({
identityPoolId: awsconfig.aws_cognito_identity_pool_id, // REQUIRED - Amazon Cognito Identity Pool ID
region: awsconfig.aws_cognito_region, // REQUIRED - Amazon Cognito Region
refreshHandlers: {
[AUTH_CONFIG.domain]: refreshFunction(idToken, (exp * 1000))
},
});
console.log({ authConfig });
const federatedCreds = await Auth.federatedSignIn(
AUTH_CONFIG.domain,
{
token: idToken,
// expires_at means the timestamp when the token provided expires,
// here we can derive it from the expiresIn parameter provided,
// then convert its unit from second to millisecond, and add the current timestamp
expires_at: exp * 1000 // the expiration timestamp
},
user
);
console.log({ federatedCreds });
const currentCreds = await Auth.currentCredentials();
console.log({ currentCreds });
const storageConfig = await Storage.configure({
AWSS3: {
// REQUIRED - Amazon S3 bucket
bucket: awsconfig.aws_user_files_s3_bucket,
// OPTIONAL - Amazon service region
region: awsconfig.aws_user_files_s3_bucket_region,
},
});
return {
authConfig,
federatedCreds,
storageConfig,
};
}
The error picture given above is thrown when it gets to the Auth.federatedSignIn
call
@grimunit I managed to get it working at some point using the federated authentication. I think what you're missing is you need to enable the idp in your identity pool. If you got the page of your snap shots where you show the unauthenticated role and authenticated role and go to the Authentication providers you should see something like this
If I remember correctly the lack of permissions your error is referring to is related to the idp provider you need to enable there.
A piece of warning though, if you use this method of authenticating via auth0 and cognito, unless you map attributes from auth0 to cognito attributes, you won't get much user information and also the username for the user logging in will be composed like so yourIdpName_auth0|generatedId
so it looks something like this auth0test_auth0|5d9c81872fce3b0ded382444
. You are authenticating with cognito via sts.
@hyprstack Hmm shoot, unfortunately I already do have that part checked :/ So you didn't have to do anything with the thumbprint thing to get it to work?
@grimunit Nope. I never used the thumbprint, nor did I have any issues with it. Maybe look into permissions for STS authentication. That's what it boils down to in the end if you use this flow.
On the other hand, if you're interested, this is what I did in end
Having Third party OIDC in the normal workflow like facebook/google social auth is, would likely reduce the amount of "special case" documentation needed. Solving https://github.com/aws-amplify/amplify-cli/issues/177 would go a long way to solving this for me. The various parts of amplify that rely on having a Cognito user pool to work with, mean that despite the fact I'd get charged twice, I'd probably end up using Auth0 (or any other third party authentication provider) as an OIDC auth endpoint for a "regular" Cognito user pool to make sure that everything works, effectively just substituting "login with google/facebook" for "login with Auth0".
Edit: Their is currently an open PR to fix https://github.com/aws-amplify/amplify-cli/issues/177, its https://github.com/aws-amplify/amplify-cli/pull/3409
Auth0 also have nice docs that could help: https://auth0.com/docs/integrations/integrating-auth0-amazon-cognito-mobile-apps
@sw-yx, as @grimunit mentioned in November, the documentation provided by Auth0 is falling behind with changes being made by AWS.
https://docs.amplify.aws/lib/auth/advanced/q/platform/js#federate-with-auth0
auth0-spa hides the idToken. get it with:
const claims = await auth0Client.getIdTokenClaims();
const idToken = claims.__raw;
Problem Statement
AWS Amplify does a great job for documentation around adding AWS Cognito authentication, however, many organizations have authentication providers such as Auth0 or Okta they use for application sign on.
Proposal
If you dig enough into Github issues you can find snippets of suggestions on how you should approach this. It would be great if you provided documentation section around using these external providers. By adding these other providers it widens the adoption of tooling like this.
Related