Client Initiated Backchannel Authentication specifies a new authentication flow, by means of which the RP's that know the user identifier they want to authenticate (e-mail, phone number), will be able to initiate an interaction flow to authenticate their users without having end-user interaction from the consumption device. The flow is a direct communication from the Client to the OpenID Provider without redirect through the user's browser (consumption device).
CIBA enables a Client to initiate the authentication of an end-user by means of out-band mechanisms.
5. Client Registration for CIBA flow
• Clients need to configure the method their prefer to deliver the result of the
authentication:
• Polling mode
• Notification mode
CIBA flow
• Client sends the CIBA authentication request to the OP
• OP authenticate the user through the Authentication Device
• Delivery of the authentication result: id_token, access_token, refresh_token
• Polling mode
• Notification mode
6. Tech Mobile Connect server initiated OIDC profile
• Based on MODRNA CIBA spec with some differences, most significant
differences…
• Only Notification Mode is allowed
• Signed RequestObject is MANDATORY
• Only asymmetric signatures
• Use of response_type = mc_si_async_code to identify Notification mode
• A lot of more parameters within the RequestObject
7. AD
OP
CIBA FLOW
1 CIBAAuthentication Request
User Interactions
3
CLIENT
2
CIBAAuthentication Request Acknowledgement
4 CIBA Polling RequestToken
5
Token
8. AD
OP
CIBA FLOW
1 CIBAAuthentication Request
User Interactions
3
CLIENT
2
CIBAAuthentication Request Acknowledgement
4
Token
As clients using polling mode don't
have any redirect_uri nor
client_notification_endpoint to be
listed in the document pointed by the
sector_identifier_uri, they can't be
proven as clients allowed to use such
sector_identifier_uri, so is not possible
to use PPID for these cases
9. CIBA
MODRNA
Authentication
Profile
OpenID Connect Core
bc-authorize
endpoint
• OpenID Connect implements authentication as an
extension to the OAuth 2.0 by including the openid
scope value in the Authorization Request.
scope
REQUIRED
• Unique id provided by the Client that will be used by
the OpenID Provider as a bearer token to authenticate
the callback request to send the tokens.
client_notification_token
REQUIRED only when
Notification mode is used
• As defined in OpenID Connect MODRNA
Authentication Profile.
acr_values
REQUIRED
• login_hint_token
• id_token_hint
• login_hint
A hint is REQUIRED, but only
one from
10. POST /bc-authorize HTTP/1.1
Host: server.example.com
Content-Type: application/json
{
"scope": "openid",
"client_notification_token": "8d67dc78-7faa-4d41-aabd-67707b374255",
"acr_values": "mod-mf",
"login_hint_token": "eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgck
CL9kiMT03JGeipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb Sv04uVuxIp5Zms1gNxKKK2 Da14B8S4rzVRltdYwam_
lDp5XnZAYpQdb76FdIKLaVmqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je81860ppamavo35UgoRdbYa Bcoh9QcfylQr
66oc6v FWXRcZ_ZT2LawVCWTIy3brGPi6UklfCpIMfIjf7iGdXKHzg.48V1_ALb6US04U3b. 5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9
tX_EFShS8iB7j6jiSdiwkIr3ajwQzaBtQD_A.XFBoMYUZodetZdvTiFvSkQ"
}
Bearer token to
authenticate the OP
when deliver the result in
notification mode
New
endpoint!!!
11. • Unique id to identify the authentication request (transaction) made by
the Client.
auth_req_id
REQUIRED
• Expiration time of the “auth_req_id” in seconds since the auth_request
was received.
expires_in
REQUIRED
• Minimum amount of time in seconds that the Client SHOULD wait
between polling requests to the token endpoint. Only present in case of
“Polling Mode”.
interval
OPTIONAL
12. HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1",
"expires_in": 3600,
"interval": 2
}
Identifies the
transaction
univocally
It should be used by the
Client to poll the token
at the adequate pace.
15. POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
{
grant_type="urn:openid:params:modrna:grant-type:backchannel_request"
&auth_req_id=40582304823
}
New grant_type that
indicates that a token
associated to the
auth_req_id is requested.
If the OP doesn’t know the
auth_req_id that the Client is
asking for an
UNKNOWN_AUTH_REQ_ID
ERROR will be returned.
17. POST /cb HTTP/1.1
Host: client.example.com
Authorization: Bearer 8d67dc78-7faa-4d41-aabd-67707b374255
Content-Type: application/json
{
"auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1",
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEz MTEy
O DA5NzAKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6qJp6IcmD3HP99Obi1PRs-cwh3LO-p146 waJ8IhehcwL7F09J
dijmBqkvPeB2T9CJNqeGpegccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7TpdQyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF
_m 0_N0YzFC6g6EJbOEoRoSK5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
}
In the ”Notification
Mode” the Token is not a
Response to a Request, it
is deliver in an HTTP
POST Request.
Bearer Token to
authenticate the OP. It is
the
client_notification_token
value sent in the
authentication request.
This delivery mode
requires to identify the
transaction associated
with this token