RequestedSubjectValidator Class

Records the end users a claims request will accept for sub, so the endpoint can honour them when it chooses a session.

public class RequestedSubjectValidator : Abblix.Oidc.Server.Endpoints.Authorization.Validation.SyncAuthorizationContextValidatorBase

Inheritance System.Object → SyncAuthorizationContextValidatorBase → RequestedSubjectValidator

Remarks

This is the second way of asking what id_token_hint asks, and OpenID Connect Core 1.0 Section 3.1.2.2 states them as one requirement: "If the sub (subject) Claim is requested with a specific value for the ID Token, the Authorization Server MUST only send a positive response if the End-User identified by that sub value has an active session with the Authorization Server or has been Authenticated as a result of the request. The Authorization Server MUST NOT reply with an ID Token or Access Token for a different user, even if they have an active session with the Authorization Server. Such a request can be made either using an id_token_hint parameter or by requesting a specific Claim Value as described in Section 5.5.1, if the claims parameter is supported by the implementation."

The condition attached to that MUST is met here rather than left open: the discovery document advertises claims_parameter_supported, so a client is entitled to expect the parameter to decide something. What makes a request name somebody lives in RequestedSubjects(this RequestedClaims), shared with the decoupled endpoint that accepts the same parameter without a browser.

Runs beside IdTokenHintValidator and after the validators that resolve the redirect URI and the response mode, for the same reason: its refusals are the kind RFC 6749 Section 4.1.2.1 says the client must be told about by redirection, and before those there is nowhere to tell it.