FAPI Client Initiated Backchannel Authentication Profile - draft

4.1. Client initiated backchannel authentication security provisions

When this profile is used with the FAPI 1.0 specifications then it should be read in conjunction with OpenID Connect Client Initiated Backchannel Authentication Core [CIBA] and with parts 1 [FAPI1.1] and 2 [FAPI1.2] of the FAPI 1.0 Specifications.¶

When this profile is used with the FAPI 2.0 specifications then it should be read in conjunction with OpenID Connect Client Initiated Backchannel Authentication Core [CIBA] and the FAPI 2.0 Security Profile [FAPI2].¶

4.2. Accessing protected resources

The benefit of the CIBA specification is that once tokens are issued they can be used in the same manner as tokens issued via authorization code flows.¶

When this profile is used with the FAPI 1.0 specifications, the provisions for accessing protected resources detailed in [FAPI1.1] and [FAPI1.2] apply fully.¶

When this profile is used with the FAPI 2.0 specifications, the provisions for accessing protected resources detailed in [FAPI2] apply fully.¶

4.3. Registration and discovery metadata

This specification adds additional metadata parameters for OAuth authorization server metadata as defined in [RFC8414] and dynamic client registration metadata as defined in [RFC7591].¶

OAuth authorization server metadata:¶

1. backchannel_endpoint_login_hint_token_types_supported: OPTIONAL. JSON array of strings that the authorization server can use to advertise which types of login_hint_token it supports. The values in this parameter are likely to be ecosystem specific.¶

Dynamic client registration metadata:¶

1. backchannel_endpoint_login_hint_token_types: OPTIONAL. JSON array of strings that the client can use to register the type of login_hint_token that it will use.¶

5.1. Introduction

The [CIBA] specification introduces some new attack vectors not present in OAuth 2 redirect based flows. This profile aims to help implementers of [CIBA] for higher security needs to reduce or eliminate these attack vectors. There are however further security considerations that should be taken into account when implementing this specification.¶

It is strongly recommended to use OAuth 2 redirect based flows secured by [FAPI1.1], [FAPI1.2] or [FAPI2] for the same device use cases because decoupled flows suffer from session binding limitations that are not present in redirect flows. This specification is designed to cater for cross device and user not present scenarios.¶

5.2. Authentication sessions started without a users knowledge or consent

As this specification allows the client to initiate an authentication request it is important for the authorization server to know whether the user is aware and has consented to the authentication process. If widely known user identifiers (e.g. phone numbers) are used as the login_hint in the authentication request then this risk is worsened. An attacker could start unsolicited authentication sessions on large numbers of authentication devices, causing distress and potentially enabling fraud.¶

For this reason this profile highly recommends login_hint to have the properties of a nonce with the expectation being that it will be generated from an authorization server owned client authentication device. Given the high levels of friction that this may impose it's anticipated that authorization servers may have to accept an id_token_hint as an alternative mechanism for client subject identification.¶

If a client wishes to store the id_token returned from an authorization server for later use as an id_token_hint, care must be taken to ensure that the customer identification mechanism used to retrieve the id_token is appropriate for the channel being used.¶

For illustration a QR code on a 'club card' may be an appropriate identifier when using a POS terminal under CCTV but it might not be an appropriate identifier when used in online ecommerce.¶

In addition, [CIBA] provides an optional user_code mechanism to specifically mitigate this issue, it may be appropriate to require the use of user_code in certain deployments.¶

5.3. Reliance on user to confirm binding messages

Depending on the hint used to identify the user and the client's user authentication processes, it may be possible for a fraudster to start a malicious [CIBA] flow at the same time as a genuine flow, with both flows using the genuine user’s identifier. If the scope of access requested is similar then the only way to ensure that a user is authorizing the correct transaction is for the user to compare the binding messages on the authentication and consumption devices.¶

If this risk is deemed unacceptable then implementers should either consider alternative mechanisms of verifying the binding message (e.g. conveying it to the authentication device via a QR code), or use ephemeral user identifiers generated on the authentication device.¶

5.4. Loss of fraud markers to authorization server

In a redirect-based flow, the authorization server can collect useful fraud markers from the user-agent. In a [CIBA] flow the separation of consumption and authentication devices reduces the data that can be collected. This could reduce the effectiveness of any fraud detection system.¶

5.5. Incomplete or incorrect implementations of the specifications

To achieve the full security benefits, it is important the implementation of this specification, and the underlying OpenID Connect and OAuth 2.0 specifications, are both complete and correct.¶

The OpenID Foundation provides tools that can be used to confirm that an implementation is correct:¶

https://openid.net/certification/¶

The OpenID Foundation maintains a list of certified implementations:¶

https://openid.net/developers/certified/¶

Deployments that use this specification should use a certified implementation.¶

5.6. JWS/JWE Algorithm considerations

When this profile is used with the FAPI 1.0 specifications, authorization servers and clients shall follow the guidance around JWT signing and encryption algorithms in [FAPI1.2] 8.6 and 8.6.1.¶

When this profile is used with the FAPI 2.0 specifications, authorization servers and clients shall follow the guidance around cryptography and secrets in [FAPI2] 5.4.¶

5.7. Authentication device security

This profile and the underlying specifications do not specify how the authorization server should initiate and perform user authentication and authorization of consent on the authentication device.¶

Implementors must use appropriately strong methods to communicate with the authentication device and to authenticate the end user.¶

5.8. CIBA token delivery modes

[CIBA] defines 3 ways that tokens can be delivered to the client.¶

The push mode is not permitted by this specification as it delivers tokens to the client by calling an endpoint owned by the client. This substantially differs from the established pattern of retrieving tokens by presenting client authentication to the token endpoint, and it may have security concerns that are currently unknown.¶

The poll and ping modes both follow the established convention of retrieving tokens from the token endpoint and hence do not have this concern.¶

The ping mode delivers a notification to an endpoint owned by the client. The information contained in this notification is limited to the auth_req_id for the request, as described in [CIBA] 10.2. The bearer token used by the authorization server to access this resource is not sender constrained. If the backchannel_client_notification_endpoint, the auth_req_id and the client_notification_token are known to an attacker, they may be able to force the client to call the token endpoint repeatedly or before the authentication has completed. For most deployments this is not a significant issue.¶

5.9. TLS considerations

As confidential information is being exchanged, all interactions shall be encrypted with TLS (HTTPS).¶

The recommendations for Secure Use of Transport Layer Security in [BCP195] shall be followed, with the following additional requirements:¶

1. TLS version 1.2 or later shall be used for all communications.¶
2. A TLS server certificate check shall be performed, as per [RFC6125].¶
3. Only the cipher suites recommended in [BCP195] shall be permitted.¶

5.10. Algorithm considerations

For JWS, both clients and authorization servers:¶

1. shall use PS256 or ES256 algorithms;¶
2. should not use algorithms that use RSASSA-PKCS1-v1_5 (e.g. RS256);¶
3. shall not use none;¶

5.11. Encryption algorithm considerations

For JWE, both clients and authorization servers¶

1. shall not use the RSA1_5 algorithm.¶

8.1. OAuth authorization server metadata registration

This specification adds the following values to the IANA "OAuth Authorization Server Metadata" registry established by [RFC8414]:¶

• Server Metadata Name: backchannel_endpoint_login_hint_token_types_supported¶
• Server Metadata Description: Supported CIBA login hint token types.¶
• Change Controller: OpenID Foundation Financial-Grade API Working Group - openid-specs-fapi@lists.openid.net¶
• Specification Document(s): Section 7 of [[this specification]]¶

8.2. OAuth dynamic client registration metadata registration

This specification requests registration of the following client metadata definitions in the IANA "OAuth Dynamic Client Registration Metadata" registry established by [RFC7591]:¶

• Client Metadata Name: backchannel_endpoint_login_hint_token_types¶
• Client Metadata Description: The supported CIBA login hint token types that the client will use to initiate CIBA requests.¶
• Change Controller: OpenID Foundation Financial-Grade API Working Group - openid-specs-fapi@lists.openid.net¶
• Specification Document(s): Section 7 of [[this specification]]¶

9.1. Signed authentication request with private_key_jwt client authentication

This example includes various optional fields, some of which may not be applicable to some deployments. Line wraps within values are for display purposes only.¶

POST /backchannel-authorization-endpoint HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

request=eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6InRocndxbnVl
ciJ9.eyJpc3MiOiIzMDExODMzNzM4MTQ5NzkiLCJhdWQiOiJodHRwczovL3NlcnZ
lci5leGFtcGxlLmNvbS8iLCJpYXQiOjE1NjQ5MDI3MzgsIm5iZiI6MTU2NDkwMjc
zOCwiZXhwIjoxNTY0OTAzMDM4LCJqdGkiOiJBSnhaUnBOcWxnNjJVVGR5MzdndSI
sInNjb3BlIjoib3BlbmlkIHBheW1lbnRzIiwiYWNyX3ZhbHVlcyI6InVybjptYWN
lOmluY29tbW9uOmlhcDpzaWx2ZXIgdXJuOm1hY2U6aW5jb21tb246aWFwOmJyb25
6ZSIsImNsaWVudF9ub3RpZmljYXRpb25fdG9rZW4iOiJfTWlVT1kwN0VPQ3ZXUjV
CVnVPTD0iLCJsb2dpbl9oaW50Ijoiam9obkBleGFtcGxlLmNvbSIsImJpbmRpbmd
fbWVzc2FnZSI6IlMyNFIiLCJ1c2VyX2NvZGUiOiI2MzY1IiwicmVxdWVzdGVkX2V
4cGlyeSI6IjEyMCIsInJlcXVlc3RfY29udGV4dCI6eyJsb2NhdGlvbiI6eyJsYXQ
iOjUxLjE3Mzk3LCJsbmciOi0xLjgyMjM4fX0sInBheW1lbnRfaW50ZW50Ijp7ImF
tb3VudCI6IjE2NS44OCIsImN1cnJlbmN5IjoiR0JQIiwiY3JlZGl0b3JfYWNjb3V
udCI6eyJzY2hlbWVfbmFtZSI6IlVLLk9CSUUuU29ydENvZGVBY2NvdW50TnVtYmV
yIiwiaWRlbnRpZmljYXRpb24iOiIwODA4MDAyMTMyNTY5OCIsIm5hbWUiOiJBQ01
FIEluYyJ9fX0.6YQ2j27lXlsfw5QFUoDDbkXJnu8ldi6Tw8LwUEg_C1w2ru_tksY
yIN81jv4Q0NXwRBtWsojahPFynZJa39Q3Yg&
client_assertion=eyJraWQiOiJ0aHJ3cW51ZXIiLCJhbGciOiJFUzI1NiJ9.ey
JzdWIiOiIzMDExODMzNzM4MTQ5NzkiLCJhdWQiOiJodHRwczovL3NlcnZlci5leG
FtcGxlLmNvbS8iLCJpc3MiOiIzMDExODMzNzM4MTQ5NzkiLCJleHAiOjE1NjQ5MD
I3OTgsImlhdCI6MTU2NDkwMjczOCwianRpIjoiNnNSVndWdVpseDFERUJjSEVIaH
gifQ.b9fpM3hUv5Nex9DZOYS8AGUiBMIFnlvf5YgRmUqzBhljIGr4M5f-mkt2VOM
ImaKe-LaUMeD5y_PZGaBiDTo50A&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-asser
tion-type%3Ajwt-bearer

which contains the JWT payload:¶

{
  "iss": "301183373814979",
  "aud": "https://server.example.com/",
  "iat": 1564902738,
  "nbf": 1564902738,
  "exp": 1564903038,
  "jti": "AJxZRpNqlg62UTdy37gu",
  "scope": "openid payments",
  "acr_values": "urn:mace:incommon:iap:silver urn:mace:incommon:iap:bronze",
  "client_notification_token": "_MiUOY07EOCvWR5BVuOL=",
  "login_hint": "john@example.com",
  "binding_message": "S24R",
  "user_code": "6365",
  "requested_expiry": "120",
  "request_context": {
    "location": {
      "lat": 51.17397,
      "lng": -1.82238
    }
  },
  "payment_intent": {
    "amount": "165.88",
    "currency": "GBP",
    "creditor_account": {
      "scheme_name": "UK.OBIE.SortCodeAccountNumber",
      "identification": "08080021325698",
      "name": "ACME Inc"
    }
  }
}