Class SenderConstraintViolationEvent

Namespace

Fdyay.IdentityServer.Events

Assembly

Fdyay.IdentityServer.Core.dll

A sender-constrained access token was presented without the proof of possession it is bound to.

public class SenderConstraintViolationEvent : Event

Inheritance

object

Event

SenderConstraintViolationEvent

Inherited Members

Event.Category

Event.Name

Event.EventType

Event.Id

Event.Message

Event.TimeStamp

Event.ActivityId

Event.RemoteIpAddress

Event.LocalIpAddress

Event.ProcessId

Event.PrepareAsync()

Event.ToString()

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.MemberwiseClone()

object.ReferenceEquals(object, object)

Remarks

What this means, stated plainly, because it is the reason the event exists: the token carries a cnf claim naming a key or a certificate, and the request presenting it did not demonstrate possession of that key or certificate. A bearer token in that position is a token being used by somebody it was not issued to. The server is right to refuse — and until 0.63.0 it refused six different ways and told nobody at all. Not an event, not a log line: the class held no logger.

The third of a set that was two. This server detects the misuse of three credentials — a refresh token replayed after consumption, a DPoP proof replayed, and now a bound token presented without its binding — and had events for two. 0.45.0 built the detection and left the audit half unbuilt, which is §1e's own shape standing in the surface whose job is to notice things.

The reason is carried rather than split into types, and that is the opposite call from 0.57.0's three session events, made for the opposite reason. There an operator does something different about a revocation and an expiry, so folding them behind a field would have put the distinction where no alert rule could read it. Here all six refusals mean one thing and prompt one investigation; the reason tells whoever is looking which wire-level mistake was made, and is diagnostic rather than an alerting key.

It names the client and subject the token was issued to, because the useful question is whose token is being presented by somebody else. It never carries the token, matching every other event here: the one thing a log store must not hold is the credential itself.

Constructors

SenderConstraintViolationEvent(string, string, string?, string?)

A bound access token presented without the proof of possession it is bound to.

public SenderConstraintViolationEvent(string confirmationMethod, string reason, string? clientId, string? subjectId)

Parameters

confirmationMethod string

The binding the token carries — see ConfirmationMethod.

reason string

Which way the binding went unsatisfied — one of SenderConstraintViolationReasons.

clientId string

The client the token was issued to, when it carries one.

subjectId string

The user the token was issued for, when it carries one.

Properties

ClientId

The client the token was issued to, when it carries one.

public string? ClientId { get; }

Property Value

string

ConfirmationMethod

The binding the token carries — jkt, x5t#S256, or one this server cannot read.

public string ConfirmationMethod { get; }

Property Value

string

Reason

Which of the ways the binding went unsatisfied. Diagnostic, not an alerting key.

public string Reason { get; }

Property Value

string

SubjectId

The user the token was issued for, when it carries one — absent for a machine token.

public string? SubjectId { get; }

Property Value

string