1. 2022-01-14
Client Initiated Backchannel Authentication
(CIBA) and Authlete’s Approach
Tatsuo Kudo
Authlete, Inc.

2. Typical AuthZ/AuthN Flow Using a Single Device
Source: HubSpot and Google
6
1 3 4
2
5
7
6. Login completed
API
2. AuthZ/AuthNrequest
3. “Sign in”
4. ID/Password etc.
5. Access token (AT) / ID token
7. API access with AT
1. Start
Client (Relying
Party)
Authorization /
API Server
(Identity Provider)
User
Device

3. Decoupling AuthZ/AuthN from Service Consumption
1. Attempt to use 3. Authenticate
2. AuthZ /
AuthN Req
Client (Relying
Party)
Authorization /
API Server
(Identity Provider)
User
Device Smartphone

4. Consumption from a Device Not Owned by the User
3. Authenticate
2. AuthZ /
AuthN Req
Client (Relying
Party)
Authorization /
API Server
(Identity Provider)
User
POS Terminal Smartphone
1. Attempt to use
0. Start

5. Consumption by Someone Who Is Not the User
3. Authenticate
Client (Relying
Party)
Authorization /
API Server
(Identity Provider)
User
Desktop Smartphone
1. Attempt to use
2. AuthZ /
AuthN Req
Operator
0. Start

6. AuthZ/AuthN Initiated by Client via Backchannel
User
3. Access token (AT) / ID token
1. AuthZ/AuthN request by
specifying an identifier of the user
Client (Relying
Party)
Authorization /
API Server
(Identity Provider)

7. • An OAuth/OIDC flow that separates a device into:
– Consumption Device (CD) that interacts with a client
– Authentication Device (AD) to authenticate a user
• “Browser redirect” is no longer required
– A client makes a “backchannel authentication
request” directly to an authorization server (AS)
– AS sends a notificationto the user’s AD to
authenticate, and create tokens once authenticated
– Client eventually obtains an access token from AS’
token endpoint (when using Pull/Ping mode)
CIBA (Client Initiated Backchannel Authentication)
https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0-final.html

8. The CIBA Flow
User
Consumption
Device (CD)
Authentication
Device (AD)
Client
(Relying Party)
Authorization / API Server
(Identity Provider)
0
0. Determine
the user’s
identifier
login_hint_token
id_token_hint
login_hint
1
1. Make a authentication
request
BA EP
2a
2a. Provide ”Authentication
Request ID”
2b
2b. User
Authentication
API
3
(*) Access Token
(**) Refresh Token
3. Provide authentication
result and tokens using
Poll / Ping / Push mode
User Identifier
AuthN Req ID
ID Token / AT* / (RT**)
Backchannel
Authentication Endpoint
4a AT
4b ID Token
4a. Make an API
request with
token
4b. Identify the user
using the
authentication result

9. CIBA Support in Authlete’s Semi-hosted Architecture
API Infrastructure
Authorization Server
API Servers / Gateways
/data /function /transaction
Authlete
Authorization
Information
(e.g. Tokens)
Database
Backchannel
authN request
API access w/
access token
/auth/introspection API
/…
Authlete
API
Token request
(Poll/Ping mode)
Consumption
Device (CD) Client
Confidential
Client
Authentication
Device (AD)
Desktop
Mobile
POS Terminal
User
Start
User Authentication
Mobile
Notification for
user authN
Authentication and Consent
User AuthN
Consent
Mgmt
Entitlement
Mgmt
Request for
user
notification
User
notification
done
Token EP (No
changes req’d)
User
authN
done
/backchannel/authentication API
Backchannel
AuthN EP (New)
/backchannel/authentication/issue API
/backchannel/authentication/complete API
/auth/token API

10. 1. Forward content of a backchannelauthentication request from a
client to /backchannel/authenticationAPI to obtain a ticket
2. Send the ticket to /backchannel/authentication/issue API once a
user notification is done, to obtain backchannelauthentication
response content to be sent to the client
3. Send the ticket etc. to /backchannel/authentication/complete
API once a user authentication is done so that Authlete can prepare
tokens to be provided in the next step
4. Forward content of a token request from the client to /auth/token
API to obtain token response content
How Authorization Server Uses Authlete APIs

11. Thank You
Tatsuo Kudo
www.linkedin.com/in/tatsuokudo