Class BackChannelAuthenticationUserValidationContext

Namespace

Fdyay.IdentityServer.Validation

Assembly

Fdyay.IdentityServer.Core.dll

The hints a client sent to say who it wants authenticated.

public sealed class BackChannelAuthenticationUserValidationContext

Inheritance

object

BackChannelAuthenticationUserValidationContext

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.ReferenceEquals(object, object)

object.ToString()

Properties

BindingMessage

The binding message the client sent, when it sent one.

public string? BindingMessage { get; init; }

Property Value

string

Client

The client that asked.

public required Client Client { get; init; }

Property Value

Client

IdTokenHintClaims

The claims of the id_token_hint, when the client sent one — already validated.

public IReadOnlyCollection<Claim>? IdTokenHintClaims { get; init; }

Property Value

IReadOnlyCollection<Claim>

Remarks

Unlike the other two hints this one is not an assertion the client made up: it is an identity token this server signed and issued to this same client, so its signature, issuer, type and audience have been checked before this is called, and its sub is a subject this server already knows. Its lifetime is not checked — a hint says who, it does not authenticate them, and the user still answers on their own device. What is left to the host is the same question every hint leaves: whether to act on it. The subject returned must be the hint's own sub; a different one is refused.

LoginHint

The login_hint, when the client sent one.

public string? LoginHint { get; init; }

Property Value

string

Remarks

Whatever the client and this server have agreed identifies a person — a username, an email address, a customer number. It is an unauthenticated assertion by the client about who it wants to reach, which is why resolving it is the host's job and not a string comparison this library could do.

LoginHintToken

The login_hint_token, when the client sent one.

public string? LoginHintToken { get; init; }

Property Value

string

Remarks

Opaque here on purpose. CIBA Core leaves its format to the parties, so this server carries it across unread rather than guessing at a structure — a host that issues them knows how to read them.

RequestedScopes

The scopes the client asked for.

public required IReadOnlyCollection<string> RequestedScopes { get; init; }

Property Value

IReadOnlyCollection<string>

UserCode

The user_code, when the client sent one — a secret the validator must check.

public string? UserCode { get; init; }

Property Value

string

Remarks

Only ever set when the host has declared, with CibaOptions.UserCodeParameterSupported, that this validator checks one; otherwise the endpoint refuses the request before it gets here. Answer MissingUserCode(string?) for a user whose requests need one and did not carry it, and InvalidUserCode(string?) for a code that is not theirs. It is a secret: this server neither stores nor logs it, and a validator should compare it in constant time.