Class ExtensionGrantValidationResult
- Namespace
- Fdyay.IdentityServer.Validation
- Assembly
- Fdyay.IdentityServer.Core.dll
Who an extension grant resolved to, or why it resolved to nobody.
public sealed class ExtensionGrantValidationResult
- Inheritance
-
ExtensionGrantValidationResult
- Inherited Members
Properties
CustomResponse
Members to add to the token response, or to the error response when the grant was refused. Duende's.
[SuppressMessage("Usage", "CA2227:Collection properties should be read only", Justification = "Duende's shape: a validator assigns it.")]
public Dictionary<string, object>? CustomResponse { get; set; }
Property Value
Error
The error to answer the client with.
public string? Error { get; }
Property Value
ErrorDescription
An optional description, returned to the client as given.
public string? ErrorDescription { get; }
Property Value
Subject
The subject the issued token acts for, when the grant resolved one.
public ClaimsPrincipal? Subject { get; }
Property Value
Succeeded
Whether the grant was honoured.
public bool Succeeded { get; }
Property Value
Methods
Failure(string, string?)
The grant was refused, in the client's terms.
public static ExtensionGrantValidationResult Failure(string error, string? description = null)
Parameters
Returns
Remarks
The error reaches the client as given. A host's validator is the only thing that knows why its own grant failed, and flattening every refusal into one code would leave a client unable to tell a malformed request from a rejected one.
Success(ClaimsPrincipal)
The grant resolved a user, and the token is issued on their behalf.
public static ExtensionGrantValidationResult Success(ClaimsPrincipal subject)
Parameters
subjectClaimsPrincipal
Returns
SuccessForClient()
The grant was honoured for the client itself, with no user behind it.
public static ExtensionGrantValidationResult SuccessForClient()
Returns
Remarks
Stated rather than inferred from a null subject, because "nobody" and "this failed and said nothing" are
different answers and a result type that spells them the same way will eventually be read as the wrong
one. The token this produces is shaped like a client_credentials token, and the profile service is
not consulted for the same reason it is not consulted there: there is no user to still be active.