Amplify-js: Configure amplify to send IdToken

Created on 21 May 2019  路  8Comments  路  Source: aws-amplify/amplify-js

With userpool authentication in amplify, we would like to send idToken as authorization header instead of accessToken. Amplify API code is sending accessToken by default and looks like its not configurable.

https://github.com/aws-amplify/amplify-js/blob/0116b637ff1809310df5ee9dad48a98af91040bc/packages/api/src/API.ts#L295

With AppSync graphql test console, idToken is being sent which is different from amplify js behavior.

Wondering if there is a way to send idToken with amplify API.js?

pending-close-response-required

Most helpful comment

I am in the same situation. This is a defect or misleading in the documentation. I followed the amplify documentation for custom claims and used the Pre Token Generation Lambda Trigger.

@auth supports using custom claims if you do not wish to use the default username or cognito:groups claims from your JWT token which are populated by Amazon Cognito. This can be helpful if you are using tokens from a 3rd party OIDC system or if you wish to populate a claim with a list of groups from an external system, such as when using a Pre Token Generation Lambda Trigger which reads from a database. To use custom claims specify identityClaim or groupClaim as appropriate like in the example below:

The lambda function adds the claim to the access token but the identity claim is not sent to AppSync.

All 8 comments

To workaround, we can use app sync client with apollo-graphql, but we would like to use amplify library to leverage other features in amplify. Hoping this gets addressed soon.

@shasti421 we most likely will not make this change as using the IdToken isn't meant for this purpose. The IdToken is meant to prove who the user is when doing things such as federation or SSO. The AccessToken is used for proving what the user has access to (e.g. authorization) against an API resource. Since Amplify is designed to have best practices built in, this wouldn't be a good thing for us to change in the client. Perhaps you could let us know why you are looking to make this change and we could suggest an alternative?

This issue has been automatically closed because of inactivity. Please open a new issue if are still encountering problems.

Hey guys! I've faced the same issue. Basically I need Id Token to implement row/column based security in mapping templates. My Id Token includes a couple custom fields which are needed to implementing security. Maybe there're some alternatives, any suggestions? @undefobj

I am in the same situation. This is a defect or misleading in the documentation. I followed the amplify documentation for custom claims and used the Pre Token Generation Lambda Trigger.

@auth supports using custom claims if you do not wish to use the default username or cognito:groups claims from your JWT token which are populated by Amazon Cognito. This can be helpful if you are using tokens from a 3rd party OIDC system or if you wish to populate a claim with a list of groups from an external system, such as when using a Pre Token Generation Lambda Trigger which reads from a database. To use custom claims specify identityClaim or groupClaim as appropriate like in the example below:

The lambda function adds the claim to the access token but the identity claim is not sent to AppSync.

I have opened a related issue here where I make the case not only for why this should be addressed, but why it's actually a bug that goes against the latest documentation for AWS services.

Wondering if there is a way to send idToken with amplify API.js?

You can override Amplify's default settings to pass the id token instead

Amplify.configure({
  API: {
    graphql_headers: async () => {
      const session = await Auth.currentSession();
      return {
        Authorization: session.getIdToken().getJwtToken(),
      };
    },
  },
});

Wondering if there is a way to send idToken with amplify API.js?

You can override Amplify's default settings to pass the id token instead

Amplify.configure({
  API: {
    graphql_headers: async () => {
      const session = await Auth.currentSession();
      return {
        Authorization: session.getIdToken().getJwtToken(),
      };
    },
  },
});

Shouldn't this solution imply some security concerns?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

guanzo picture guanzo  路  3Comments

josoroma picture josoroma  路  3Comments

DougWoodCDS picture DougWoodCDS  路  3Comments

epicfaace picture epicfaace  路  3Comments

callmekatootie picture callmekatootie  路  3Comments