Class PresentedAccessToken

Namespace

Fdyay.IdentityServer.Validation

Assembly

Fdyay.IdentityServer.AspNetCore.dll

An access token as it was presented, and how.

public sealed class PresentedAccessToken

Inheritance

object

PresentedAccessToken

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.ReferenceEquals(object, object)

object.ToString()

Properties

Claims

The claims it was found to carry, which is where cnf is.

public required IReadOnlyCollection<Claim> Claims { get; init; }

Property Value

IReadOnlyCollection<Claim>

Scheme

The HTTP authentication scheme it arrived under, or null where it did not arrive in a header at all.

public string? Scheme { get; init; }

Property Value

string

Remarks

Null is not "Bearer". A token arriving as a form field — a subject token at the token endpoint — was not presented by a scheme, and a rule about which scheme a bound token must use has nothing to say about it. Spelling it Bearer would make that rule fire on a request it does not describe.

Token

The token itself, which ath is computed over.

public required string Token { get; init; }

Property Value

string

Methods

FromAuthorizationHeader(HttpRequest)

The token in this request's Authorization header, with the scheme it came under.

public static (string? Token, string? Scheme) FromAuthorizationHeader(HttpRequest request)

Parameters

request HttpRequest

Returns

(string SignatureMethod, string DigestMethod)

Remarks

One definition, because two readers need it and they have to agree: the UserInfo endpoint and the local API handler are both resource servers, and a token the one accepts under DPoP and the other reads only under Bearer would be a binding enforced at one door of two.

Both schemes, because RFC 9449 §7.1 gives a key-bound token its own, and a reader that knows only Bearer cannot be handed one correctly at all.