Amplify-js: Aws Amplify appsync API graphql cognito custom attribute

[sflamme]

I've been spending hours now trying to solve the below issue. Any help is appreciated. I am using AWS appsync graphql, cognito user pool as authentication method and simple schema

type Users {
familyId: String!
userId: String!
email: String
picture: String
givenName: String
familyName: String
...
}

type Query {
getFamily: [Users]
}
and my resolver which is using the cognito custom attributes familyID

{
"version" : "2017-02-28",
"operation" : "Query",
"index" : "familyId-index",
"query" : {
"expression": "familyId = :Id",
"expressionValues" : {
":Id" : {
"S" : "${ctx.identity.claims.get("custom:familyId")}"
}
}
},
}
This is working fine in AWSappsync query builder, also working in react native using appollo client .

This is NOT working using AWS appsync API API.graphql(graphqlOperation(getFamilyQuery)) returning error

"message": "Unable to parse the JSON document: 'Unexpected character ('c' (code 99)): was expecting comma to separate Object entries [15:07:49] at [Source: (String)\"

Remark if I replace in my resolver
"S" : "${ctx.identity.claims.get("custom:familyId")}"
with "S" : "${ctx.identity.sub}" or any fix value just to test API call is working fine... so my API client config seem fine (or do I miss something?)

It seems custom attribute is not available while using aws-Amplify API method of querying my graphql schema....

Anyone encountered the same issue? Any clue on how to solve this?

[paolocaminiti]

Same problem here while trying to use custom attributes from cognito to manage sub users access control. This largely makes appsync unusable for non trivial user scenarios.

[sflamme]

Ok thanks. Will have to use Apollo client instead as custom attributes are
key to my authorization logic

On Sun, Sep 30, 2018, 2:07 PM Paolo Caminiti [e-mail]
wrote:

Same problem here while trying to use custom attributes from cognito to
manage sub users access control.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/aws-amplify/amplify-js/issues/1772#issuecomment-425716293,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Apnzz30JoiJF-_LPF3lMUhsk7adtaPN9ks5ugLP5gaJpZM4W8pGB
.

[paolocaminiti]

@sflamme Please note that mine was not an answer, we just had a similar issue and find no solution other than having a middle table for queries and gave up mutations granular access control.

Somebody from amazon should step in with a solution or the confirmation that there is a bug. For sure the inconsistency between the online dashboard and the appysinc client library is alone a major issue.

[orucrob]

Playing with this issue a little bit and found a problem: claims are not available, when you are using access token here: https://github.com/aws-amplify/amplify-js/blob/0116b637ff1809310df5ee9dad48a98af91040bc/packages/api/src/API.ts#L295

when you change it to :
Authorization: session.getIdToken().getJwtToken()

your claims are available and I'm able to get them this way in resolver:

#set( $perm = $context.identity.claims["custom:perm"])

More about tokens

[sflamme]

!!!! respect
you're the man.
Totally works and solve it indeed....
Not sure if there is any unwanted associated border effect?

On Wed, Oct 3, 2018 at 10:39 AM Rob [e-mail] wrote:

Playing with this issue a little bit and found a problem: claims are not
available, when you are using access token here:
https://github.com/aws-amplify/amplify-js/blob/0116b637ff1809310df5ee9dad48a98af91040bc/packages/api/src/API.ts#L295

when you change it to :
Authorization: session.getIdToken().getJwtToken()

your claims are available and I'm able to get them this way in resolver:

set( $perm = $context.identity.claims["custom:perm"])

More about tokens
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aws-amplify/amplify-js/issues/1772#issuecomment-426556384,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Apnzz0rcA9ahUH375a4DFsnKMO0fuEysks5uhHe1gaJpZM4W8pGB
.

[orucrob]

I believe there is no unwanted effect.

Because from the doc:

The user pool access token contains claims about the authenticated user, but unlike the ID token, it does not include identity information.

The access token expires one hour after your user successfully authenticates

The ID token is a JSON Web Token (JWT) that contains claims about the identity of the authenticated user such as name, email, and phone_number. You can use this identity information inside your application. The ID token can also be used to authenticate users against your resource servers or server applications.

The ID token expires one hour after the user authenticates.

This is the only difference:

The header for the access token will have the same structure as the ID token, but the key ID (kid) will be different because different keys are used to sign ID tokens and access tokens.

So that's why I believe it has no side effect in context of this issue.
But it wants at least one more opinion... ;-)

[sflamme]

Lots of thanks!!! Makes my app security logic so much easier and my
resolver more straight forward.

On Wed, Oct 3, 2018, 12:00 PM Rob [e-mail] wrote:

I believe there is no unwanted effect.

Because from the doc
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html#amazon-cognito-user-pools-using-the-access-token
:

The user pool access token contains claims about the authenticated user,
but unlike the ID token, it does not include identity information.

The access token expires one hour after your user successfully
authenticates

The ID token is a JSON Web Token (JWT) that contains claims about the
identity of the authenticated user such as name, email, and phone_number.
You can use this identity information inside your application. The ID token
can also be used to authenticate users against your resource servers or
server applications.

The ID token expires one hour after the user authenticates.

This is the only difference:

The header for the access token will have the same structure as the ID
token, but the key ID (kid) will be different because different keys are
used to sign ID tokens and access tokens.

So that's why I believe it has no side effect in context of this issue.
But it wants at least one more opinion... ;-)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aws-amplify/amplify-js/issues/1772#issuecomment-426578753,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Apnzz_XsT3BQyfcT0jdOEzQWHSvXXJQ3ks5uhIrDgaJpZM4W8pGB
.

[paolocaminiti]

Great!

[sflamme]

Hi,

Coming back to this issue. It seems there is security concern regarding the
use of IdToken for accessing an API.
Standard seems to indicate that only access token should be used.

https://auth0.com/docs/api-auth/why-use-access-tokens-to-secure-apis

So that triggers the following questions:

• when using the local AWS appsync query builder why this is working?
  where does the context info come from?
• when using Apollo 2.1 query HOC why this is working? where does the
  context comes from?

Is there a way to have AWS SDK working using Access Token only as per the
standard?

Any thoughts,

Stephane

On Wed, Oct 3, 2018 at 10:39 AM Rob [e-mail] wrote:

Playing with this issue a little bit and found a problem: claims are not
available, when you are using access token here:
https://github.com/aws-amplify/amplify-js/blob/0116b637ff1809310df5ee9dad48a98af91040bc/packages/api/src/API.ts#L295

when you change it to :
Authorization: session.getIdToken().getJwtToken()

your claims are available and I'm able to get them this way in resolver:

set( $perm = $context.identity.claims["custom:perm"])

More about tokens
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aws-amplify/amplify-js/issues/1772#issuecomment-426556384,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Apnzz0rcA9ahUH375a4DFsnKMO0fuEysks5uhHe1gaJpZM4W8pGB
.

[erik-induro]

I was trying to use the following auth rule vai the Amplify CLI:

@auth(rules: [{ allow: owner, ownerField: "tenant", identityField: "custom:tenant" }])

But found that the custom attribute isn't being passed from the app but is from the console, as was mentioned above. This makes it harder to support multi-tenancy. Any update on this?

[sflamme]

Hi,

This is not a bug but a behaviour conform to standard.
As indicated by Rob in previous answer, if you use the AccessToken for
calling your API only the userId is present and all other profile
information is missing (as per OAUTH standard).
My understanding so far.

*So either you change your API call to use the IdToken *
"Playing with this issue a little bit and found a problem: claims are not
available, when you are using access token here:
https://github.com/aws-amplify/amplify-js/blob/0116b637ff1809310df5ee9dad48a98af91040bc/packages/api/src/API.ts#L295

when you change it to :
Authorization: session.getIdToken().getJwtToken()

your claims are available and I'm able to get them this way in resolver:

set( $perm = $context.identity.claims["custom:perm"])

More about tokens
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html
"

With the following security concern (which I am not expert enough to judge
the validity)

The standard state clearly

https://auth0.com/docs/api-auth/why-use-access-tokens-to-secure-apis

“ The ID Token is a JSON Web Token (JWT) https://auth0.com/docs/jwt,
and it is meant for the application only….The Access Token (which isn't
necessarily a JWT), is meant for use by an API.”

“ID Tokens should not be used to gain access to an API. Each token contains
information for the intended audience (which is usually the recipient). Per
the OpenID Connect specification, the audience of the ID Token (indicated
by the aud claim) must be the client ID of the application making the
authentication request. If this is not the case, you should not trust the
token. Conversely, an API expects a token with the aud value to equal the
API's unique identifier. Therefore, unless you maintain control over both
the application and the API, sending an ID Token to an API will generally
not work. Furthermore, the ID Token is signed with a secret known only to
the application itself. If an API were to accept an ID Token, it would have
no way of knowing if the application has modified the token (such as adding
more scopes) and resigned it.”

Either you respect the standard to the letter and you only have
$ctx.identity.sub available at your APIGW.

You can use for instance a pipeline resolver to first get the profile of
your user from a user table (copy of cognito via lambda trigger) and then a
second resolver to actually perform the operation itself. Using pipeline
resolver you can really implement fine grain authorization logic with
multiple criterias.

It is more work, but worth the effort as you can implement more complex
scenario.

I've both solutions up and running.

Regards,

Stephane

On Sat, Jan 12, 2019 at 8:20 PM Erik Murphy [e-mail]
wrote:

I was trying to use the following auth rule vai the Amplify CLI:

@auth(rules: [{ allow: owner, ownerField: "tenant", identityField: "custom:tenant" }])

But found that the custom attribute isn't being passed from the app but is
from the console, as was mentioned above. This makes it harder to support
multi-tenancy. Any update on this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aws-amplify/amplify-js/issues/1772#issuecomment-453773980,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Apnzz8fdp3YnApOOJvTHNn4z8IcoXNdeks5vCjVwgaJpZM4W8pGB
.

[undefobj]

@sflamme comment is correct, the token information in the AccessToken is not the same as the IdToken. This seems to be working as expected. Can we close this issue?

[buggy]

The AppSync console sends the identity token instead of the access token. Sending the identity token instead of the access token would be my preference because Cognito User Pools allows you to modify the claims in the identity token but not the access token. It does seem like a few of us are using the identity token to hold tenant information.

[elorzafe]

I think the is clear now, anyone feel free to create a new one in case there are any new concerns.