Closed hanna-becker closed 1 year ago
hanna-becker
commented
1 year ago Upon further investigation I can see that the groups are being passed on in the Graphql request, but the custom claim isn't. Meaning, the idToken that I see in dev tools network tab, when decoded, has a "cognito:groups" array, but is missing my "project:invitee" claim, even though both are present in my local storage's idToken.
hanna-becker
commented
1 year ago Also, overriding the api config like mentioned in the other issue makes no difference for me:
// V6
import { Amplify } from "aws-amplify";
import { fetchAuthSession } from "aws-amplify/auth";
import config from "./amplifyconfiguration.json";
Amplify.configure(config, {
API: {
GraphQL: {
headers: async () => ({
Authorization: (
await fetchAuthSession()
).tokens?.idToken?.toString() as string,
}),
},
},
});Whether I have this override or not, in both cases the idToken of the request has "cognito:groups", but not "project:invitee".
hanna-becker
commented
1 year ago So in summary it seems like the idToken that my pre token generator lambda produces with correct values is being decoded, the non-group custom claim stripped away, and then reencoded before making the API call to AppSync somewhere in the client.
hanna-becker
commented
1 year ago New update: The override above does work to patch the "project:invitee" claim, I just got the syntax wrong. Still wondering why without this override group claims are passed on automatically, while others are stripped away from the id token?
hanna-becker
commented
1 year ago If it is intended behavior that non-group custom claims get stripped from the id token, while group custom claims aren't, I'm ready to close this issue. Otherwise it'd be worth investigating/fixing this behvior.
chrisbonifacio
commented
1 year ago Hi @hanna-becker 👋 thank you for raising this issue and providing us the context of your troubleshooting.
I will discuss this with the team to confirm if it is expected behavior.
Also, out of curiosity, when you said:
The override above does work to patch the "project:invitee" claim, I just got the syntax wrong
Does this mean you are unblocked and able to use custom claims again? Lastly, what was the change you had to make for it to work?
hanna-becker
commented
1 year ago Hi @chrisbonifacio, thank you for getting back to me so quickly!
Yes, I'm unblocked. After reading a bit more, I believe what I'm observing is expected: Normally, the header contains the access token, which includes the Cognito groups (in my case the ones added in the pre token generator lambda). But any additional custom claims (in my case "project:invitee") are only included in the id token, so to use them we need to configure amplify to send the id token, instead of the access token when making api calls:
import { Amplify } from "aws-amplify";
import { fetchAuthSession } from "aws-amplify/auth";
import config from "./amplifyconfiguration.json";
Amplify.configure(config, {
API: {
GraphQL: {
headers: async () => ({
Authorization: (
await fetchAuthSession()
).tokens?.idToken?.toString() as string,
}),
},
},
});The reason it didn't work initially is that I got confused with the syntax (the header now gets passed in a second argument to Amplify.configure, while in v5 it got passed as part of the first arg). It works now!
The whole topic of adding/overriding group and custom claims needs way better documentation, though. There is already an open ticket for better docs around custom claims, and I will add a suggestion there and close this ticket.
Before opening, please confirm:
JavaScript Framework
Angular
Amplify APIs
Authentication, GraphQL API, Storage
Amplify Categories
auth, storage, function, api
Environment information
Describe the bug
This bug is related to the one opened here, but slightly different, as it affects custom claims, not group claims. While GROUP claims still work for queries and mutations in our case, CUSTOM claims stopped working altogether in amplify v6.
This is our model of a Project. There are members that have read-write permissions and there are invitees that have read-only permissions:
In the pre token generation lambda, we add those permissions as custom/group claims, respectively:
Looking at the idToken in the browser (In Chrome dev tools: Application -> Local storage -> localhost/app url -> CognitoIdentityServiceProvider.{{sth.sth}}.idToken -> decode value e.g. here: https://jwt.io/), I can see the claims are still being set correctly from the pre token lambda function. The payload json looks something like this (ids are altered for this post). This is for my test user who is a full member of 2 projects (read-write access) and invited to another one (read-only access). :
However, when querying read-only projects for this user, I get an unauthorized error from the grapqhql API call, indicating the read-only claim is potentially not being applied correctly:
"errorType":"Unauthorized" "message":"Not Authorized to access getMusicProject on type Query"
This is working with amplify v5.
As opposed to the subscription issue I referenced above, we know the idToken is being passed down correctly for the query. Otherwise we would also see authorization errors for for the 2 projects our test user is a member of. But there seems to have been some parsing logic on the custom claim in v5 that is not there any more or different in v6.
Expected behavior
We can use custom claims as in v5 without getting unauthorized errors.
Reproduction steps
Reproduction steps:
Code Snippet
Log output
Manual configuration
No response
Additional configuration
No response
Mobile Device
No response
Mobile Operating System
No response
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
No response