!!! Overview
[{$pagename}] ([CIBA]) is a [specification] written by [MODRNA] [Working Group] of [OpenID Foundation] defines a new [OAuth 2.0] [Grant Type] where user consent can be requested through an [Out of Band Request] flow.. 


[{$pagename}] public review period for the [specification] started on Dec. 14, 2018 and it was approved on Feb. 4, 2019.

[CIBA] flows, the [Authorization Server] delegates the tasks of [End-User] [authentication] and [consent] confirmation to an [authentication] [device] of the end-user. A [smartphone|Mobile Device] is a typical [example] of authentication devices. This process is performed on the background after a response is returned from the backchannel [authentication] [endpoint] to the [OAuth Client] [application].

[{$pagename}] flows allows the [OAuth Client] [application] is not under the control of the [End-User] and it can be physically separated from the [authentication] device. For example, [CIBA] can support a use case where a [OAuth Client] application is running on a computer in front of an operator working in a call center in Okinawa, while end-user authentication and consent confirmation are performed on a smartphone at the hand of the end-user who has made the call to the call center from Tokyo.

[{$pagename}] allows the ability to complete the [authorization], the user can receive a push [Notification] sent to the financial institution’s native mobile app running on the user’s phone, allowing the customer to avoid confusing [Redirection] via web [browsers].

!! [Financial API] ([FAPI]) [{$pagename}]
There is also a [FAPI] version of [{$pagename}] that supports this decoupled interaction method. The [CIBA] spec allows a client that gains knowledge of an identifier for the user to obtain [tokens] from the [Authorization Server]. The user consent is given at the user's Authentication Device mediated by the [Authorization Server]. This document profiles the CIBA specification to bring it in line with the other [FAPI] parts and provides security recommendations for its use with [APIs] that require [financial-grade security|Financial API].

Although it is possible to code an [OpenID Connect Provider] and [Relying Party] from first principles using this specification, the main audience for this specification is parties who already have a certified [implementation] of [OpenID Connect] and want to achieve a higher level of security. Implementors are encouraged to understand the security considerations contained in section 7.5 before embarking on a 'from scratch' [implementation].


[{$pagename}] makes [app2app] possible.


!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - ["CIBA", a new authentication/authorization technology in 2019, explained by an implementer|https://medium.com/@darutk/ciba-a-new-authentication-authorization-technology-in-2019-explained-by-an-implementer-d1e0ac1311b4|target='_blank'] - based on information obtained 2019-08-05 
* [#2] - [OpenID Connect Client Initiated Backchannel Authentication Flow|https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html|target='_blank'] - based on information obtained 2019-08-05 
* [#3] - [IMPROVING THE CUSTOMER EXPERIENCE WITH CLIENT INITIATED BACKCHANNEL AUTHENTICATION (CIBA)|https://www.pingidentity.com/en/company/blog/posts/2019/client-initiated-backchannel-authentication-improving-customer-experience.html|target='_blank'] - based on information obtained 2019-08-05 
* [#4] - [Implementer’s Draft of FAPI Client Initiated Backchannel Authentication (CIBA) Profile Approved|https://openid.net/2019/08/23/implementers-draft-of-fapi-client-initiated-backchannel-authentication-ciba-profile-approved/|target='_blank'] - based on information obtained 2019-09-04