Consent and Claims
On this page
User Consent and Claims
In modern identity and access management (IAM), understanding the interplay between user consent and claims is crucial. Consent involves allowing users to decide what personal data to share with third parties, while claims are assertions about a user's identity used by applications to make authorization decisions.
Asking for Consent
When a user grants consent, they authorize:
- the identity provider to release specific claims to a relying party (the application)
- the authorization server to include specific claims in an access token, which will allow the client (the application) to access the user's resources
Note that the two situations can happen in one authorization flow — some claims will be released to the relying party via an ID token and some claims will be associated with an access token.
These claims can include information such as the user's name, email address, or roles within an organization.
Third parties
Consent is normally not used when the Client and the OpenID Connect Provider belong to the same organization. In that case, the user is often considered to have implicitly consented to the use of the information in question. Consent is more commonly involved when the Client is a Third Party.
Implementing Consent Mechanisms
To effectively manage user consent and the issuance of claims, you should implement robust consent management mechanisms. This includes providing clear information to users about what data will be shared, with whom, and for what purposes. Additionally, users should have the ability to review and revoke their consent as needed, ensuring compliance with privacy regulations such as the General Data Protection Regulation (GDPR).
Consent and Claims
The consent screen presented to the user contains all the Claim Names with corresponding descriptions for each claim.
In the Curity Identity Server, it is possible to configure the consentto allow deselects for each claim. Since the application may ask for data that the user isn't willing to release, it is important that the user be able to use the application to release only some of the data requested.
User deselection
If the user deselects claims during consent, these will not be provided to the Client. The Client should be robust enough to handle such scenarios.
If deselection isn't possible to manage in the Client, the Client can be configured to not allow deselection. This will provide the user with the option of releasing all or nothing, essentially aborting the authorization.
Resulting Claims
Following consent, the ID Token and Access Tokens will contain the claims that the user consented to. Claims are mapped; some will be present in the ID Token and others in the access token.
Conclusion
Consent is a powerful and important way for Third Party Clients to inform the user about data that is being shared. The Client needs to be robustly built in order to handle cases where the user doesn't consent to the release of certain claims.
By understanding and properly managing the relationship between consent and claims, you can enhance user trust and ensure that authorization decisions are made based on accurate and user-approved information.
Jacob Ideskog
Identity Specialist and CTO at Curity
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
Start Free Trial
