The parameters for device risk determination in Decoupled AuthZ/AuthN Protocol(OIDC CIBA, XYZ, XAuth)

4 min readMar 3, 2020

This post discusses putting risk-based concepts into protocols that support Decoupled AuthN/AuthZ.

Timing to judge risks with OIDC

In the standard AuthN flow of OIDC, the OpenID Provider can perform risk judgment when receiving an authentication request.
For example, depending on its decision, OpenID Provider can require the user for additional authentication or skip authentication.
This is because Client and OpenID Provider are running in the same device.
The same judgment can be made when a client that is a native application launches an external browser and sends an authentication request.

On the other hand, in the case of decoupled AuthZ/AuthN flow, the device where the client is running (like “CD” in CIBA) and the device where the OpenID Provider interacts with the user (like “AD” in CIBA) are different.
In a protocol that supports such a flow, the Client sends the authentication request on the back channel and OpenID Provider requests the user interaction(see CIBA’s sequence).
In such a situation, how can the OpenID Provider determine the risk of the client’s device?
We already know systems that perform such risk-based authentication.
I referred to 3D Secure 2.0 to think about this.

Risk-based AuthN for 3D Secure 2.0

The 3D Secure 2.0 guide provided by Stripe is very helpful for me to get an overview.
Note the section on “Frictionless Authentication”.

3D Secure 2 allows businesses and their payment provider to send more data elements on each transaction to the cardholder’s bank. This includes payment-specific data like the shipping address, as well as contextual data, such as the customer’s device ID or previous transaction history.
If the data is enough for the bank to trust that the real cardholder is making the purchase, the transaction goes through the “frictionless” flow and the authentication is completed without any additional input from the cardholder.

Replace it with OIDC terminology and remove the payment-specific part …

Client adds its device (and/or session) information to the AuthN request
OpenID Provider determines the risk from the information received, and if it is low, grants access without interaction

The device information sent in 3D Secure 2.0 for risk-based authentication is defined as EMV® 3-D Secure SDK — Device Information.
There are platform-independent values such as IP addresses and device names. In addition, there are values defined for each platform, such as iOS, Android, and Windows 10.
This data is acquired and transmitted by using an SDK certified to conform to the specifications.

# Device Info for Android (from spec)
{"DV":"1.0", # DV: Data Version"DD":{"C001":"Android","C002":"HTC One_M8","C004":"5.0.1","C005":"en- US","C006":"Eastern Standard Time","C007":"06797903-fb61-41ed-94c2-4d2b74e27d18","C009":"John's Android Device",....}, # DD: Device Data"DPNA":{"C010":"RE01","C011":"RE03"}, # DPNA: Device Parameter Not Available"SW":["SW01","SW04"] # SW: Security Warning. For information about Security Warning, refer to the EMV 3-D Secure SDK Specification.}

For web browser-based, there is a list of values defined within the 3D Secure 2.0 specification.

Browser Accept Headers
Browser IP Address
Browser Java Enabled
Browser Language
Browser Screen Color Depth
Browser Screen Height
Browser Screen Width
Browser Time Zone
Browser User-Agent

With frictionless flow, payment is completed without user interaction.
Even if you make multiple payments from different apps running on the same device in a short period of time, you may be able to complete all processes with one user interaction without requiring each user interaction as a separate transaction.

Extension to add device information

3D Secure 2.0’s approach can be applied to protocols that support Decoupled AuthN/AuthZ.

Representation of Device information

First, it is necessary to express a lot of device information mentioned above as a parameter.
OAuth 2.0/OIDC has several solutions.

Serialization using JWT (like OIDC “request” param)
URI hosting JSON or JWT (like OIDC “request_uri” param or OAuth 2.0 PAR extension)

For device information, the following parameters can be defined:

“device_info” : device information in JWT format
“device_info_uri” : URI where device information is hosted

JWT Payload or JSON body contains device information.

# JWT's Payload and device_uri response
{
 "platform":"Android", "device_model":"HTC One_M8", "os_version":"5.0.1", ... "device_name":"John's Android Device", ...
}

The Client includes this parameter in the AuthZ/AuthN request, and the OpenID Provider uses it to make risk decisions.

For CIBA

For CIBA, the Client adds device information parameters to the authentication request.

POST /bc-authorize HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded

scope=openid%20email%20example-scope&
client_notification_token=8d67dc78-7faa-4d41-aabd-67707b374255&
binding_message=W4SCT&
login_hint_token=eyJraWQiOiJsdGFjZXNidyIsImFsZyI6IkVTMjU2In0.eyJ
zdWJfaWQiOnsic3ViamVjdF90eXBlIjoicGhvbmUiLCJwaG9uZSI6IisxMzMwMjg
xODAwNCJ9fQ.Kk8jcUbHjJAQkRSHyDuFQr3NMEOSJEZc85VfER74tX6J9CuUllr8
9WKUHUR7MA0-mWlptMRRhdgW1ZDt7g1uwQ&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
client-assertion-type%3Ajwt-bearer&
client_assertion=eyJraWQiOiJsdGFjZXNidyIsImFsZyI6IkVTMjU2In0.eyJ
pc3MiOiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHB
zOi8vc2VydmVyLmV4YW1wbGUuY29tIiwianRpIjoiYmRjLVhzX3NmLTNZTW80RlN
6SUoyUSIsImlhdCI6MTUzNzgxOTQ4NiwiZXhwIjoxNTM3ODE5Nzc3fQ.Ybr8mg_3
E2OptOSsA8rnelYO_y1L-yFaF_j1iemM3ntB61_GN3APe5cl_-5a6cvGlP154XAK
7fL-GaZSdnd9kg&
device_info=eyJ....eyJ... # NEW!!!

OpenID Provider performs risk assessment of device information in addition to Authentication Request Validation.

If the risk is low, the OpenID Provider can skip End-User’s Consent/Authorization.
For compatibility, the OpenID Provider will avoid returning tokens immediately from the Backchannel Authentication Endpoint.
The response from Backchannel Authentication Endpoint does not change, and the OpenID Provider returns Ping / Push immediately or returns a token immediately in Poll response.

For XYZ, XAuth

For XYZ, the Resource Client adds a “device_info” section to the Transaction Request.
This section has a “value” or “uri” field.

# use JWT
”device_info": {
  "value": "eyJ...eyJ..."
}# use URI
”device_info": {
  "uri": "https://ritou.example.com/device_info/abcdefg..."
}

XYZ also defines a response with no user interaction, so no other changes are required.
XAuth also includes “device_info” in Request JSON like XYZ.

User's permission

Device fingerprinting for tracking uses similar data.
Clients should explain the purpose of use before collecting device information and request user permission if necessary.

The timing of device risk judgment is different between OIDC redirect flow and flow that supports Decoupled AuthN
In 3D Secure 2.0, Client sends device or browser information as a parameter to use for risk judgment
I have defined additional parameters to introduce this method to Decoupled AuthN.

As Decoupled AuthN becomes popular, it may become a user burden to perform AuthN / AuthZ processing many times on the terminal at hand.
I think risk assessment can safely reduce the it.