Backchannel sign-in and FAPI 2.0

Two things for clients with stricter needs than a browser redirect:

• Backchannel sign-in (CIBA). An application that already knows who the user is (a call centre, a point-of-sale terminal, a device with no browser) asks rIDM to have that user sign in on their own device. It never sees a browser; it collects the tokens once the user approves. This is OpenID Client-Initiated Backchannel Authentication (CIBA) Core 1.0.
• The FAPI 2.0 Security Profile. A client can be held to the profile open-banking and other high-assurance APIs ask for: pushed requests, PKCE, sender-constrained tokens, strong signatures, and nothing weaker accepted from it.

Both are per client. Neither changes how any other client works.

Backchannel sign-in (CIBA)

Registering a client for it

The client needs the grant urn:openid:params:grant-type:ciba in allowed_grants, and it must be confidential: CIBA requests are always authenticated. In the console, tick Backchannel (CIBA) under Grants & authentication and choose the delivery.

Both fields are refused on a client without the grant; remove them in the same change that removes the grant. Signed authentication requests and user codes are not supported, and a dynamic registration that asks for either (backchannel_authentication_request_signing_alg, backchannel_user_code_parameter: true) is refused.

The request

curl https://id.example.com/t/acme/bc-authorize \
  -u "bank:$SECRET" \
  -d scope="openid profile" \
  -d login_hint=alice@example.com \
  -d binding_message="K7 R2"

{ "auth_req_id": "Vh2…", "expires_in": 600, "interval": 5 }

Exactly one hint must be present. A hint that names no active, unlocked user is unknown_user_id. At most five requests may wait on one user at a time; a sixth is access_denied, so no client can flood someone’s inbox.

What the user sees

rIDM emails the user (or texts them, if they have a verified phone and no email) the backchannel_request message: who is asking, the binding message, and a link to Requests in the account console, /account/approvals/. The link carries the request’s own id, never the auth_req_id. The notice is sent whatever settings.notifications says, because without it nobody learns there is anything to approve. Its template can be overridden like any other; see Email, SMS and templates.

The page lists what waits on the user: the application, its binding message, the scopes, and when the request expires. The user signs in to the account console if they are not already, then approves or denies. An approval:

• gives the client tokens as if the user had signed in to it from the session they approved in: the ID token’s sid, auth_time, amr and acr are that session’s, and a refresh token without offline_access ends with it;
• is remembered as consent, so the application appears under Applications and can be removed there like any other.

A request is answered once. Approving needs a signed-in session: a personal access token cannot approve (403), or a leaked one could turn itself into the user’s tokens at any CIBA client. A session opened by impersonation cannot answer at all (403), and one user can never see or answer another’s request.

Collecting the tokens

curl https://id.example.com/t/acme/token \
  -u "bank:$SECRET" \
  -d grant_type=urn:openid:params:grant-type:ciba \
  -d auth_req_id=Vh2…

Until the user answers, the token endpoint says authorization_pending; asking again within the interval says slow_down and adds five seconds to it. A denial is access_denied and an expired request expired_token, each once. An approval is handed over at once, whatever the interval, and only once: after that the auth_req_id is invalid_grant. Only the client that asked can collect.

In ping mode rIDM POSTs, as soon as the user answers:

POST /cb HTTP/1.1
Authorization: Bearer <client_notification_token>
Content-Type: application/json

{"auth_req_id": "Vh2…"}

It tries three times over about five seconds through the same outbound guard as back-channel logout (no private addresses unless the operator opened them with OUTBOUND_ALLOW_NETWORKS). A ping client that never hears can still poll.

Audit

backchannel.requested (actor: the client) when a request opens, authorization.granted when the user approves, backchannel.denied when they refuse. The ciba_requests table keeps every request’s outcome for the tenant’s retention period.

The FAPI 2.0 Security Profile

Set security_profile: "fapi2" on a client (in the console: Security profile → FAPI 2.0 Security Profile). Registration then refuses anything outside the profile, and every request from the client is held to it.

A resource server that asks for RS256 access tokens cannot be a FAPI client’s audience: such a request is invalid_target.

With mutual TLS the client may authenticate with its certificate instead of private_key_jwt, and a client registered for certificate-bound tokens is sender-constrained by its certificate: it needs no DPoP proof, and DPoP defaults to off for it. Without either binding the registration is refused.

Requiring PAR without the profile

require_pushed_authorization_requests: true (RFC 9126 §6) makes /authorize refuse any request of that client that did not come through /par, with none of the profile’s other rules. A FAPI 2.0 client always requires PAR. Dynamic registration accepts the field and stores it.