ConsentDefinition Class
Defines the details of user consents required for specific scopes and resources. This record is used to manage and validate user consent for accessing specific scopes, resources, and RFC 9396 Rich Authorization Requests entries, ensuring that consent is explicitly granted according to the requirements of the application and compliance standards.
public record ConsentDefinition : System.IEquatable<Abblix.Oidc.Server.Features.Consents.ConsentDefinition>Inheritance System.Object → ConsentDefinition
Implements System.IEquatable<ConsentDefinition>
Constructors
ConsentDefinition(ScopeDefinition[], ResourceDefinition[]) Constructor
Defines the details of user consents required for specific scopes and resources. This record is used to manage and validate user consent for accessing specific scopes, resources, and RFC 9396 Rich Authorization Requests entries, ensuring that consent is explicitly granted according to the requirements of the application and compliance standards.
public ConsentDefinition(Abblix.Oidc.Server.Common.Constants.ScopeDefinition[] Scopes, Abblix.Oidc.Server.Common.Constants.ResourceDefinition[] Resources);Parameters
Scopes ScopeDefinition[]
An array of ScopeDefinition that represents the scopes for which user consent is needed.
Resources ResourceDefinition[]
An array of ResourceDefinition that represents the resources for which user consent is needed.
Properties
ConsentDefinition.AuthorizationDetails Property
RFC 9396 authorization_details entries for which user consent is needed (in
Pending) or has been granted (in Granted).
null when the request did not include authorization_details.
public System.Text.Json.Nodes.JsonArray? AuthorizationDetails { get; init; }Property Value
System.Text.Json.Nodes.JsonArray
Remarks
The two sets are independent, so a decision is made per entry: an entry the user has approved goes to Granted while another from the same request is still waiting in Pending. Anything left pending sends the request back for consent, and the screen is shown what is pending rather than what has already been granted.
A granted entry is whatever the provider returns, which RFC 9396 section 7.1 permits to differ from
what was requested, in either direction: dropping an entry keeps it out of the issued token, editing
one inside (an amount narrowed by a slider) is carried through as edited, and the section's own example
is the opposite case, the server filling in the accounts a user picked. What is refused is a granted
entry of a type the request did not carry; within an entry, the per-type validator decides.
Only the authorization endpoint consults this. A backchannel authentication request has no consent seam at all, and the device flow surfaces the requested entries for the host to carry onto the grant itself.
The storage is raw so that member order, type-specific payload and members this server does not model
survive the round trip untouched. For rendering a consent screen, read the same entries as
AuthorizationDetail through ToTypedArray(): the typed view wraps these
nodes rather than copying them, so it names the RFC 9396 section 2.2 common members without costing the
rest.
ConsentDefinition.Resources Property
An array of ResourceDefinition that represents the resources for which user consent is needed.
public Abblix.Oidc.Server.Common.Constants.ResourceDefinition[] Resources { get; init; }Property Value
ConsentDefinition.Scopes Property
An array of ScopeDefinition that represents the scopes for which user consent is needed.
public Abblix.Oidc.Server.Common.Constants.ScopeDefinition[] Scopes { get; init; }