Backchannel authentication (CIBA)

OpenID Connect CIBA Core 1.0, all three delivery modes — poll, ping and push. The flow with no browser in it: a client asks this server to authenticate a user who is not in front of it — an agent with the customer on the phone, a payment terminal, a service that needs a person to approve something it is about to do — and the server goes and finds them. The recorded flow shows a poll-mode client's requests and responses. The code on this page is included from samples/Protocols.Ciba, which a test boots against a SQLite file: it starts requests, finds them in the database and at the user's device, approves one and redeems it.

Turning it on

It is off by default, and it is the only endpoint here that is. Every other endpoint can answer a request with what this library alone knows. This one cannot, so it needs two implementations from the host, and UseIdentityServer() refuses to start with the endpoint enabled and either missing:

var identityServer = builder.Services.AddIdentityServer(options =>
{
    options.KeyManagement.Enabled = false;

    // Off by default, and UseIdentityServer() refuses to start with it on and either host service missing.
    options.Endpoints.EnableBackchannelAuthenticationEndpoint = true;

    // StaffUserValidator checks a user_code, so this host says so. Off, a request carrying one is refused.
    options.Ciba.UserCodeParameterSupported = true;
});

// The two things only the host can answer: who a hint names, and how to reach them.
builder.Services.AddSingleton<StaffDirectory>();
builder.Services.AddTransient<IBackchannelAuthenticationUserValidator, StaffUserValidator>();
builder.Services.AddSingleton<IBackchannelAuthenticationUserNotificationService, DevicePrompts>();

Service	What only the host can answer
IBackchannelAuthenticationUserValidator	What a `login_hint` means. A hint is an unauthenticated assertion by a client about who it wants to reach; turning it into a subject is an agreement between a deployment and its clients. This is also where a rule about which clients may ask after which users belongs. An `id_token_hint` arrives already validated, as `IdTokenHintClaims`, and a `user_code` arrives for it to check — both below
IBackchannelAuthenticationUserNotificationService	How to reach that person — a push notification, an SMS, a message into an app they already have open. It is awaited before the client is answered, so a host that cannot reach the user fails the request instead of handing back an `auth_req_id` nobody will act on

Neither has a default implementation, and the missing one is deliberate. A no-op notifier would turn "this host has not finished wiring CIBA up" into "CIBA is slow today" — every request would be accepted, expire unanswered, and look exactly like a user ignoring their phone.

/// <summary>
/// What a hint means here: a <c>login_hint</c> is a member of staff's email address, and an <c>id_token_hint</c>,
/// already validated by the server, names them by subject id. A member of staff who set a PIN must be asked with it.
/// </summary>
public sealed class StaffUserValidator(StaffDirectory staff) : IBackchannelAuthenticationUserValidator
{
    /// <inheritdoc />
    public Task<BackchannelAuthenticationUserValidationResult> ValidateAsync(
        BackChannelAuthenticationUserValidationContext context, CancellationToken cancellationToken = default)
    {
        ArgumentNullException.ThrowIfNull(context);

        var hinted = context.IdTokenHintClaims?.FirstOrDefault(claim => claim.Type == JwtClaimTypes.Subject)?.Value;
        var member = hinted is not null ? staff.FindBySubjectId(hinted)
            : context.LoginHint is not null ? staff.FindByEmail(context.LoginHint)
            : null;

        if (member is null)
        {
            return Task.FromResult(BackchannelAuthenticationUserValidationResult.UnknownUser());
        }

        // A code sent for somebody who has none is wrong, not ignored, so trying cannot tell who has one.
        if (member.Pin is null)
        {
            return Task.FromResult(context.UserCode is null
                ? BackchannelAuthenticationUserValidationResult.Success(member.SubjectId)
                : BackchannelAuthenticationUserValidationResult.InvalidUserCode());
        }

        if (context.UserCode is null)
        {
            return Task.FromResult(BackchannelAuthenticationUserValidationResult.MissingUserCode());
        }

        return Task.FromResult(CryptographicOperations.FixedTimeEquals(
                Encoding.UTF8.GetBytes(member.Pin), Encoding.UTF8.GetBytes(context.UserCode))
            ? BackchannelAuthenticationUserValidationResult.Success(member.SubjectId)
            : BackchannelAuthenticationUserValidationResult.InvalidUserCode());
    }
}

/// <summary>
/// How a member of staff is reached: a prompt on the device the request named. The queue stands in for a push
/// notification service. The prompt links to the request's internal id, never its <c>auth_req_id</c>, which is the
/// client's credential for the tokens.
/// </summary>
public sealed class DevicePrompts : IBackchannelAuthenticationUserNotificationService
{
    /// <summary>The prompts sent, newest last.</summary>
    public ConcurrentQueue<DevicePrompt> Sent { get; } = new();

    /// <inheritdoc />
    public Task NotifyAsync(BackChannelAuthenticationRequest request, CancellationToken cancellationToken = default)
    {
        ArgumentNullException.ThrowIfNull(request);

        // What DeviceEnrolment accepted from the request is on it, in Properties.
        Sent.Enqueue(new DevicePrompt(
            request.SubjectId,
            request.Properties["device"],
            request.BindingMessage,
            $"/ciba?id={request.InternalId}"));
        return Task.CompletedTask;
    }
}

/// <summary>A prompt asking a member of staff to approve a request on one of their devices.</summary>
public sealed record DevicePrompt(string SubjectId, string Device, string? BindingMessage, string ApprovalLink);

The demo host's src/Fdyay.IdentityServer.Host/DemoBackChannelAuthentication.cs is the smallest honest pair: it resolves hints against its test users and logs the approval link, because a demo has no phone to ring.

A client is registered for the grant, confidential, because a backchannel request has no browser and no redirect URI to tie it to anything but its credentials:

// The default delivery mode, poll: the client asks the token endpoint until the user has answered.
new Client
{
    ClientId = "teller-console",
    ClientSecrets = { new Secret("teller-console-secret".Sha256()) },
    AllowedGrantTypes = { OidcConstants.GrantTypes.Ciba },
    AllowedScopes = { "openid", "profile", "accounts" },
},

The client starts a request at /connect/ciba, authenticated, with no browser and no redirect URI, and is answered an auth_req_id, its expires_in and the interval to poll at. Until the user answers, a poll is answered authorization_pending — slow_down when it comes faster than the interval, access_denied or expired_token when there is nothing more to wait for — and then with the tokens. How long a user has, the longest lifetime a client may ask for and the polling interval are CibaOptions.

Pending requests, on every instance

A pending request is state, and where it lives decides whether the flow works on more than one instance. By default it is held in process. That is the one store whose in-memory default bites hardest: a device authorization is answered within minutes by whoever is holding the device, while a backchannel request arrives with nobody in front of it and is answered whenever that person next reaches the approval surface — so the window in which it has to be visible to every instance is its whole lifetime. A client polling one instance while the user answers on another waits out its expiry for an answer that already exists.

// Pending requests in the database, so every instance sees every request: a client may poll one instance while the
// user answers on another. DatabaseProvider.SqlServer for SQL Server.
identityServer.AddDapperStores(options =>
{
    options.Provider = DatabaseProvider.Sqlite;
    options.ConnectionString = builder.Configuration.GetConnectionString("IdentityServer")
        ?? throw new InvalidOperationException("ConnectionStrings:IdentityServer is not set.");

    // Only needed when narrowing Stores at all: BackChannelAuthentication is in DapperStores.All, the default.
    options.Stores = DapperStores.PersistedGrants | DapperStores.BackChannelAuthentication;

    // Nothing else prunes the table, and most requests are never answered.
    options.EnableTokenCleanup = true;
});

The sweep removes requests past their expiry and never ones merely answered — a completed request whose client has not polled yet is still owed its answer, and deleting it would turn a successful approval into a client waiting out the lifetime for a request that no longer exists. The store's settings are DapperStoreOptions; see also Persistence.

The approval page

The user answers at /ciba, which lists what is waiting for them and shows each request's binding message prominently. That message is the whole ceremony: someone approving on a device that is not the one asking has nothing else tying the request on their screen to the transaction in front of them, so a request carrying a different string is somebody else's, arriving at the same moment by design. The page reads the same scope rows the consent and device screens do, so a scope the host named is named on all three.

Every member of IBackchannelAuthenticationInteractionService takes the subject doing the answering and refuses a request belonging to anyone else. That is not defence in depth — it is the difference between "authenticate this person" and "authenticate whoever answers". The page works in the request's internal id, never the auth_req_id: the latter is the client's bearer credential for the tokens, and a browser is the last place it should be.

Being told, instead of asking (ping)

New in 0.72.0. A client registered for ping is called back when the user answers, and polls once instead of every interval until something changes:

// Ping: called back when the user answers, then redeems once at the token endpoint.
new Client
{
    ClientId = "teller-ping",
    ClientSecrets = { new Secret("teller-ping-secret".Sha256()) },
    AllowedGrantTypes = { OidcConstants.GrantTypes.Ciba },
    AllowedScopes = { "openid", "profile", "accounts" },

    BackChannelTokenDeliveryMode = OidcConstants.BackChannelTokenDeliveryModes.Ping,
    BackChannelClientNotificationEndpoint = "https://teller.example.com/ciba-notify",
},

Each request then carries a client_notification_token the client mints, which is how its endpoint knows a callback belongs to a request it made. When the user answers, this server POSTs to the registered endpoint, bearing that token:

POST /ciba-notify HTTP/1.1
Authorization: Bearer <the client_notification_token from the request>
Content-Type: application/json

{"auth_req_id":"…"}

The callback says which request was answered and nothing about the answer. The client still redeems at the token endpoint, exactly as a polling client does, and learns there whether the user approved or refused. That is what ping is in CIBA Core; push, below, is the mode whose callback carries the answer itself.

Four rules the endpoint enforces, and each has a failure it exists to prevent:

Rule	Without it
`client_notification_token` is required for ping and push	the callback would be an `auth_req_id` POSTed to a URL and asked to be believed
it is refused for poll	accepting it from a client that gets no callback would read as agreement to send one
a ping or push client must have a notification endpoint	the request would be accepted and the callback could never be sent, which a client cannot tell from a user who ignored it
a mode this server does not recognise is refused	same, one step earlier — refused at the request rather than accepted and dropped

A callback that fails does not lose the answer. The decision is recorded before anything is sent, and a failed, refused or timed-out notification is swallowed into BackChannelAuthenticationNotificationFailureEvent — so the request stays redeemable by the polling every ping client falls back to. This matters in a way that is easy to miss: the notification is sent while the user's approval is being recorded, so the user is waiting on the client's endpoint. CibaOptions.NotificationTimeout is ten seconds for that reason, the same bound every other outbound hop here uses. (0.72.0 got the timed-out case wrong: an HttpClient timeout is a TaskCanceledException, which its catch let through as if the caller had cancelled, so an endpoint that hung failed the user's approval. Fixed in 0.72.1, and the host's user notifier had the same filter and the same fix.)

Being handed the answer (push)

New in 0.73.0. A client registered for push never polls. When the user answers, this server POSTs the answer itself to the notification endpoint — the tokens, or the refusal:

// Push: never polls. The tokens, or the refusal, are posted to the notification endpoint.
new Client
{
    ClientId = "teller-push",
    ClientSecrets = { new Secret("teller-push-secret".Sha256()) },
    AllowedGrantTypes = { OidcConstants.GrantTypes.Ciba },
    AllowedScopes = { "openid", "profile", "accounts", "offline_access" },
    AllowOfflineAccess = true,

    BackChannelTokenDeliveryMode = OidcConstants.BackChannelTokenDeliveryModes.Push,
    BackChannelClientNotificationEndpoint = "https://teller.example.com/ciba-notify",
},

POST /ciba-notify HTTP/1.1
Authorization: Bearer <the client_notification_token from the request>
Content-Type: application/json

{"auth_req_id":"…","access_token":"…","token_type":"Bearer","expires_in":3600,
 "scope":"openid profile accounts offline_access","refresh_token":"…","id_token":"…"}

and on a refusal, {"auth_req_id":"…","error":"access_denied"}. The identity token carries urn:openid:params:jwt:claim:auth_req_id, at_hash, and — beside a refresh token — urn:openid:params:jwt:claim:rt_hash, so a client can check that the three values arriving at its endpoint are one answer to the request it made (CIBA Core §10.3.1).

The tokens are minted by the code a poll redeems through. Push is the one CIBA mode that issues tokens with no token request, and that was the reason 0.72.0 left it out: it looked like a second issuance path to secure. It is not one. The push redeems the stored answer through the same ITokenRequestValidator a poll goes through — the client check, the expiry, the refusal, the scopes, the profile service's say over whether the subject may still have tokens, the request spent exactly once — and builds the response with the same ITokenResponseGenerator. A host that customises either customises both modes.

Three rules come with the mode:

Rule	Why
a push client may not poll for this grant — the token endpoint answers `unauthorized_client` (CIBA Core §11)	its tokens are on their way to its endpoint; a second route to them would be a second copy of them
a push client whose tokens would be sender-constrained is refused at the request (`invalid_client`)	a pushed token has no request to carry a DPoP proof and no connection whose certificate it could confirm, so it could only be a bearer token — and the client has said it will not accept one. FAPI-CIBA forbids push for the same reason
a refusal is pushed too	a push client does not poll, so a refusal it is not sent is one it learns about only when the request expires

A push that fails loses the tokens. The answer is redeemed before it is sent, the request is spent, and the client may not poll — so a push its endpoint refuses, or that times out, is gone, and BackChannelAuthenticationNotificationFailureEvent records it. That is the trade push makes; a client that wants a failed callback to be recoverable registers for ping. The user's approval still succeeds: they answered, and an unreachable client is not their problem. A refresh token minted for a failed push stays in the grant store unreached, and is not revoked, because a push that timed out may have arrived.

Not pushed: expiry. A request nobody answers is not followed by an expired_token push. The client was told expires_in when it started the request, and nothing in this server watches pending requests expire — the sweep deletes expired rows on an interval and is not a delivery mechanism.

Discovery advertises ["poll", "ping", "push"] as backchannel_token_delivery_modes_supported.

Naming the user with an identity token (`id_token_hint`)

New in 0.74.0. CIBA Core §7.1 gives a client three ways to say who it wants authenticated, and exactly one must be sent. login_hint and login_hint_token are the client's own assertions, so resolving them is the host's job — login_hint_token is carried to the validator unread, because CIBA Core leaves its format to the parties. id_token_hint is different in kind: it is an identity token this server signed and issued to this same client, so this server checks it before the host sees it.

What makes a JWT an identity token this server issued to this client — each check keeps out something the others would admit:

Check	Keeps out
this server's signature and issuer	a token anyone else made
exactly one audience, the requesting client	a token issued to another client, which this one has no relationship with the user through
`azp` naming the client	an access token — even one whose host set `AccessTokenJwtType` to `JWT`, and even one whose API resource shares the client's name
`typ` of `JWT`	a logout token, which is addressed to the client too
a `sub`	a token that names nobody

Lifetime is not checked. A hint says who; it does not authenticate them. The user still answers on their own device whatever the hint says, so a client holding yesterday's identity token for a user is exactly the client CIBA is for. Any failure is answered invalid_request with one description, whichever check failed — saying which would help someone assemble a token that passes. The hint is bounded by InputLengthRestrictions.IdTokenHint (4000) before anything parses it.

The validated claims reach the user validator as IdTokenHintClaims — StaffUserValidator above reads its sub — and the host decides whether to act on them: a deactivated user, a client that may not ask after this one. It does not decide who they mean: a validator that answers with a subject other than the hint's sub is a host defect, answered server_error with nothing stored, rather than a request put in front of a person the client did not name.

Your own checks, and the parameters they accept

New in 0.113.0, Duende's ICustomBackchannelAuthenticationValidator: it runs last, on a request that is otherwise valid and whose user is known, and sees every parameter the client sent (Raw) beside what this server made of them. It refuses a request by replacing the result with an error — the client is told invalid_request and nothing more, and the reason reaches the failure event — or accepts custom parameters into Properties:

/// <summary>
/// A rule of the host's own, run last on an otherwise valid request: it must name the device to prompt, and that
/// parameter is kept with the request, where the notifier and the approval page read it.
/// </summary>
public sealed class DeviceEnrolment : ICustomBackchannelAuthenticationValidator
{
    /// <inheritdoc />
    public Task ValidateAsync(CustomBackchannelAuthenticationRequestValidationContext customValidationContext, CancellationToken ct)
    {
        ArgumentNullException.ThrowIfNull(customValidationContext);

        var request = customValidationContext.ValidationResult.ValidatedRequest;
        if (!request.Raw.TryGetValue("device", out var device) || string.IsNullOrEmpty(device))
        {
            // The client is told invalid_request; the description reaches the failure event.
            customValidationContext.ValidationResult = new(request, "invalid_request", "No device named.");
        }
        else
        {
            request.Properties["device"] = device;
        }

        return Task.CompletedTask;
    }
}

identityServer.AddCustomBackchannelAuthenticationRequestValidator<DeviceEnrolment>();

What it accepts is stored with the request — Properties, which the notification service is handed (DevicePrompts above reads device from it) — and is on the approval page's Properties. Without one, a request carries no properties. The name a user gives the grant when answering, ConsentResponse.Description, is recorded on the request as Description.

A secret only the user knows (`user_code`)

New in 0.75.0. A user_code is a PIN or password the user has given the client, so that naming somebody is not enough to make their phone buzz (CIBA Core §7.1). This server cannot check one — it is a secret between the user and the host — so the host's validator does, and the host has to say so, with UserCodeParameterSupported, as the sample does under Turning it on:

	`UserCodeParameterSupported = false` (default)	`true`
discovery's `backchannel_user_code_parameter_supported`	`false`	`true`
a request carrying `user_code`	refused, `invalid_request`	bounded by `InputLengthRestrictions.UserCode` (100), then handed to the validator as `UserCode`

Refused, not ignored, when the host has not opted in. A client that collected a PIN from a person and sent it believes the PIN gates the request; accepting it with nothing checking would make that false while every response looked right. Duende has no such option — it is the one place this server asks more of a host.

The validator answers with two factory methods whose error codes were measured from the Duende.IdentityModel 8.0.1 package rather than written from memory:

Result	Error	When
`MissingUserCode()`	`missing_user_code`	this user's requests need a code and this one had none
`InvalidUserCode()`	`invalid_user_code`	the code is not theirs — including when they have none, so a client cannot learn which users have one by trying

The code is never stored and never logged; it exists only in the validator's context. In the sample, lee has a PIN (4711) and dana has none; the demo host gives bob one, also 4711, and alice none.

The whole request, signed (`request`)

New in 0.76.0. A client may send its backchannel request as a JWT it signed, in request (CIBA Core §7.1.1), with a key from its registration — a JsonWebKey or X509CertificateBase64 secret, exactly as for a JAR object on /connect/authorize:

curl -X POST https://localhost:5001/connect/ciba \
  -d client_id=ciba-client -d client_secret=secret \
  -d request=eyJhbGciOiJSUzI1NiJ9…   # {"iss":"ciba-client","aud":"<issuer>","exp":…,"jti":"…",
                                       #  "scope":"openid api","login_hint":"alice","binding_message":"W4SCT"}

The object gets every check a JAR object gets — the client's own key, iss the client, aud this server, a lifetime, an algorithm from SupportedRequestObjectSigningAlgorithms, never alg=none — and two a backchannel request needs on top:

Check	Why
a `jti`	it is what makes a repeat recognisable
a `jti` not seen before (`IReplayCache`, until expiry plus skew)	a JAR object passes through a browser once; this is a direct call anyone holding it could repeat, and each repeat makes somebody's phone buzz

Any failure is invalid_request_object, one description whichever check failed. A client_id inside the object naming another client is refused too.

Only client authentication may sit beside it. client_id, client_secret, client_assertion, client_assertion_type and request itself; anything else is refused with invalid_request. An unsigned parameter next to a signed request makes a request only partly signed. Duende refuses a parameter found in both places — measured from its assembly; this refuses one found outside at all, because a value is exactly as unsigned whether or not the object also names it.

A multi-instance host wants a shared replay cache, for the same reason it already did for DPoP: one instance's memory cannot see a replay sent to another. Since 0.131.0 that means registering a real IDistributedCache — see What is kept between requests, and where. A client registered with RequireRequestObject must sign here too (since 0.82.0; see Clients that must sign). Discovery advertises backchannel_authentication_request_signing_alg_values_supported as the same list as request_object_signing_alg_values_supported.

What the client asked about signing in (`acr_values`)

New in 0.80.0. A backchannel request may carry acr_values: the authentication context classes the client wants, in order of preference, with the same tenant: and idp: hints an authorization request can carry. It is read as Duende reads it on this endpoint, measured from its assembly:


longer than `InputLengths.AcrValues` (300)	refused, `invalid_request`
the rest	split on spaces, once each, in the client's order
the first `tenant:` entry	removed from the list, its value in `Tenant`
the first `idp:` entry	removed from the list, its value in `IdP`

All three ride on the stored BackChannelAuthenticationRequest, which is what the notification service is handed, and on the BackChannelAuthenticationRequestContext the approval page reads; the /ciba page shows them. Nothing here holds the user to a class, and nothing in Duende does: if urn:example:mfa means a second factor, it is your notifier that reaches the user through something able to ask for one, or your page that asks for it before Allow.

Two differences from the authorization endpoint, both Duende's: there the hints are taken out of AuthorizationRequest.AcrValues too (since 0.164.0), but every one of them, where here a second tenant: or idp: stays in the list as a class. A bare tenant: or idp: names nothing here — null — where both endpoints of Duende's, and since 0.164.0 the authorization endpoint's, answer an empty string. An idp: outside the client's IdentityProviderRestrictions is dropped with a warning (since 0.81.0; see Who may sign in to a client).

A backchannel request takes resource indicators too; see on a backchannel request.

The CIBA validators

New in 0.121.0, as Duende's backchannel endpoint answers:

Request	Answer	Before 0.121.0
no `scope`	`invalid_request`	`invalid_scope`
a `scope` without `openid`	`invalid_request`	`invalid_scope`
a `scope` longer than `InputLengths.Scope`	`invalid_request`	accepted
a `login_hint` longer than `InputLengths.LoginHint` (100)	`invalid_request`	handed to your user validator
a `login_hint_token` longer than `InputLengths.LoginHintToken` (4000)	`invalid_request`	handed to your user validator
your user validator answering an error CIBA does not define	`unknown_user_id`	that error

Approving a request records the browser's session on it, so the tokens the client collects carry its sid and end with that session. The profile service is asked with Duende's caller, BackchannelAuthenticationRequestIdValidation.

Breaking in 0.121.0. ProfileIsActiveCallers.BackChannelAuthenticationValidation is renamed to Duende's BackchannelAuthenticationRequestIdValidation, and its value with it. A profile service that compared context.Caller with the old string no longer matches it.

The seams are Duende's: IBackchannelAuthenticationRequestValidator, IBackchannelAuthenticationResponseGenerator and IBackchannelAuthenticationRequestIdValidator, each with an open default. This server's own rules are unchanged — ping and push delivery, a request object with nothing beside it, a requested_expiry that is not a positive number ignored, and a client's polling interval only ever lengthening the server's.

How the approving user signed in

New in 0.160.0, Duende 8.0.1's DefaultBackchannelAuthenticationInteractionService.CompleteLoginRequestAsync, measured. The tokens a CIBA client collects say how the user who approved signed in, as a code's do: auth_time, idp, amr and acr when the sign-in has it, and the profile service is asked — IsActiveAsync at the poll, GetProfileDataAsync for the tokens — with every claim of that sign-in. Duende's completion clones the approving user's principal, adds auth_time (now) and idp (local) when it has none, and stores it as the request's subject; so here, as Subject (Duende's name), and the auth_req_id validator hands it to the token request. The /ciba page needs no change: its user is signed in, so a local sign-in's tokens carry its auth_time, idp=local and amr=pwd.

The approver is the session's user, IUserSession.GetUserAsync (0.158.0), as in Duende — the HTTP request's user for a session written before 0.158.0, which answers it with NotSupportedException, or when the service has no session. Only the subject's own sign-in is taken: a session whose user is somebody else, or nobody, lends the approval nothing, and the subject is recorded with its id, auth_time now and idp local — what Duende adds to a principal holding neither (Duende throws there).
This server's rules still hold: the claims service copies sub, auth_time, idp, amr, acr from the sign-in as for any grant, and the protocol-claim filter keeps the profile service from issuing sub, auth_time, idp or amr of its own.
Stored as Duende's ClaimsPrincipalLite inside the request's JSON — the authentication type and each claim's type and value, with its value type unless a string and its issuer unless LOCAL AUTHORITY — by a converter on the property, so the Dapper store needs no schema change. A request answered before 0.160.0 has no Subject, and its tokens are what they were: its subject is its id alone.
BackChannelAuthenticationInteractionService keeps its constructor, and gains one taking IHttpContextAccessor, which the container chooses.

Ours, recorded: each of the user's identities is copied before auth_time and idp are added — Duende's ClaimsPrincipal.Clone shares them, so its additions also land on the session's user; the request's user stands in for a session that cannot answer GetUserAsync, and another user's sign-in, or none, is recorded as the subject alone where Duende throws ("Invalid subject.", or the subject id mismatch); the completion here is told a subject id, where Duende's CompleteBackchannelLoginRequest.Subject may name the principal.

Table of Contents