Table of Contents

Class CibaOptions

Namespace
Fdyay.IdentityServer.Configuration
Assembly
Fdyay.IdentityServer.Core.dll

Settings for backchannel authentication (OpenID Connect CIBA Core 1.0).

public class CibaOptions
Inheritance
CibaOptions
Inherited Members

Remarks

Nothing here names a delivery mode: which one a client gets is its registration's BackChannelTokenDeliveryMode, and all three are delivered — poll since 0.27.0, ping since 0.72.0 and push since 0.73.0. What is server-wide is how long a callback may take, and whether this host checks user codes.

Properties

Interval

The minimum seconds a client should wait between polls. Defaults to 5.

public int Interval { get; set; }

Property Value

int

Remarks

Returned as interval, and enforced: polling faster is answered with slow_down. A client may be given a longer one of its own with PollingInterval.

Lifetime

How long a user has to answer a request, in seconds. Defaults to 5 minutes.

public int Lifetime { get; set; }

Property Value

int

Remarks

Longer than a device code's window would be, and for the opposite reason: the user is not standing at a screen waiting to type something, they are being interrupted. Short enough that a request nobody answered stops being answerable while the person who triggered it still remembers it.

MaximumLifetime

The longest lifetime a client may ask for with requested_expiry. Defaults to 10 minutes.

public int MaximumLifetime { get; set; }

Property Value

int

Remarks

A ceiling rather than a second default: Lifetime is what a client that asks for nothing gets, and this is as far as one that asks may go. Without the cap a client chooses how long an unanswered request stays approvable, which is not the client's decision to make.

NotificationTimeout

How long to wait for a client's ping notification endpoint. Defaults to 10 seconds.

public TimeSpan NotificationTimeout { get; set; }

Property Value

TimeSpan

Remarks

Ten seconds because that is what every other outbound hop in this tree waits — the back-channel logout notification, the JAR request_uri fetch, a client-credentials token request — and for the reason they give: somebody is waiting on the answer.

Here that somebody is the user, which is easy to miss. The notification is sent while recording their decision, so their "approve" does not come back until the client's endpoint has answered or this elapses. A generous value would let a client that registered for ping and then stopped answering hold up the person approving its requests.

For a ping, elapsing loses nothing but the callback: the answer is recorded first and stays redeemable by polling, and the failure is raised as BackChannelAuthenticationNotificationFailureEvent. For a push it loses the tokens, which were minted to travel in the callback and which the client may not poll for — the same event records it, and that is the trade a client makes by registering for push.

UserCodeParameterSupported

Whether this host's IBackchannelAuthenticationUserValidator checks a user_code. Defaults to false.

public bool UserCodeParameterSupported { get; set; }

Property Value

bool

Remarks

This server cannot check a user code — it is a secret between the user and the host — so this is the host declaring that its validator does. It decides what discovery says (backchannel_user_code_parameter_supported) and whether a request carrying a user_code is accepted. Off, one is refused rather than ignored: a client that collected a PIN from somebody and sent it believes the PIN gates the request, and accepting it with nothing checking would make that belief false while every response looked right. Duende has no such option; this is the difference.