- Mais recentes
- Mais votos
- Mais comentários
Hello,
The Identity Pool integrates with User Pool where the User Pool serves as the authentication provider. One of the benefits of this integration is that the authenticated user's groups and role association in the User Pool can be used to grant fine-grained access control in the Identity Pool. For example, you can have a rule in your Identity Pool that grants read-only permissions to the user if they belong to a read-only group in the User Pool.
The access token in the OAuth framework was not intended to contain user information like group association and attributes. You typically will use the access token to obtain the Id Token which will contain the user information. Since the fine-grained access control could rely on the user information, you will need to use the Id token to provide the user's information to the Identity Pool which you can then leverage to create rules for your fine-grained access control.
I hope this provides clarity to why Id token is used in this case.
For more information, please refer to the Role-based access control documentation - https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html
Conteúdo relevante
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há 2 meses
So you're saying that the answer is "yes", this is intentional misuse? I.e. They're they need the claims, but are trying to save a trip to the userinfo endpoint to get them? Some systems use JWT access_tokens to skip this step, but they're still access tokens. I had assumed that this is what Cognito was trying to do as their access_token was a JWT.
So assuming they are intentionally misusing id_tokens, why is their access_token a JWT? What are you supposed to do with it?
This appears to break the spec for OAuth 2.0 access tokens: https://www.rfc-editor.org/rfc/rfc9068.html#name-data-structure