Client Initiated Backchannel Authentication Profile Overview presented by Dave Tonge with moneyhub. This was presented on Wednesday, March 21, 2018 at the OpenID Foundation/Open Banking Workshop hosted by Microsoft in London.
2. I’m the CTO at , I’m an
active contributor to the FAPI
specs. I’m the FAPI WG Liaison Officer
to UK . I’m the technical rep
for .
HELLO!
A bit about me
@davidgtonge
davidgtonge
dgtonge jwt.davetonge.co.uk
3. WHY
DECOUPLED
Use cases:
▸ granting authorisation to remote call centre
agent
▸ using the strongly authenticated session
on a smart device to grant authorisation to
another device, e.g. input constrained, or
doesn’t belong to user or simply doesn’t
have a strongly authenticated session
▸ payments
5. THE CIBA FLOW
Back-channel
1. TPP to Bank: user123 wants to grant access to me
Front-channel
2. Bank to user123: do you grant access to TPP?
3. user123 to bank: yep
Back-channel
4. Bank to TPP: here is a token that allows you access
6. THE CIBA FLOW
▸ RP sends Backchannel Authentication Request to /bc_authorize, with:
▹ login_hint
▹ binding_message (optional)
▹ scope
▸ OP responds with Backchannel Authentication Response containing:
▹ auth_req_id
▸ OP obtains end-user consent/authorization. This process will normally start with a
push notification or similar. If a binding message was sent, the OP must show the
end-user the binding message and the user must confirm that it is the same as the
binding message displayed on the consumption device.
▸ RP polls /token endpoint with:
▹ grant_type:
"urn:openid:params:modrna:grant‑type:backchannel_request"
▹ auth_req_id
▸ OP responds with tokens
8. TWO PROBLEMS
Session Binding
How do you ensure that the user at the
authentication device is granting access to the
correct consumption device?
Identification
What user identifier does the relying party use and
how does it obtain it?
9. IDENTIFICATION
Four options
▸ Discovery - this works well with MNOs
▸ Static Identifier - open to abuse
▸ Dynamic single-use identifier - generated by the
bank, this also solves the binding problem
▸ Previously issued ID Token - which could have been
received via a redirect flow
All options supported by CIBA (login_hint_token,
id_token_hint & login_hint)
10. SESSION BINDING
Three options
▸ Use a dynamic single-user identifier
▸ Let the user decide - If there is enough context on
the authorisation being sought
▸ Binding message - displayed on the consumption
device, verified by the user on the authentication
device
11.
12. Takeaways
CIBA certainly solves a problem. However there are
trade-offs - it will never have the same security
properties as a redirect flow.
I’m looking forward to the day where I never have to
identify myself on the phone using my name, address
and date of birth.