This article explains technical details of Open Banking Brasil (OBB), especially differences between OBB extensions and global standard specifications.

July 24, 2021: I greatly appreciate Carol Morais and Skalena translating this article into Portuguese and publishing it at “Notas de um implementador sobre Open Banking Brasil”.

OBB Financial-grade API Security Profile

Specification Stack

OBB published “Open Banking Brasil Financial-grade API Security Profile 1.0 Implementers Draft 1” (hereinafter referred to as “OBB FAPI”) late in May, 2021. As of this writing, the specification has been being updated since then through discussion on GitHub (OpenBanking-Brasil/specs-seguranca) and in workshops and maybe somewhere else I’m unaware of. In that sense, the…

Introduction

This article is an implementer’s note about a technical specification called “JAR”, RFC 9101 The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR).

There exist some conflicts between OpenID Connect Core 1.0 (OIDC Core) and JAR. The OAuth community had a long dispute about the breaking changes because they affect existing authorization server implementations and even the OpenID conformance suite.

What are the conflicts? How were they solved? This article describes them for future readers and implementers of the JAR specification.

What is JAR?

JAR is a mechanism whereby to pack authorization request parameters into a signed JWT. A client application sends the…

Introduction

This article explains X.509 certificate.

1. Digital Signature (Prior Knowledge)

To read this article, knowledge about digital signature is needed. That is, this article assumes that you understand “By verifying signature with the public key which is paired with the private key used to generate the signature, you can confirm that the target data has been surely signed by the owner of the private key and has not been altered in transit.”

In other words, this article assumes that you know the flow illustrated below.

(1) Generate a pair of private key and public key.

(2) Pass the public key to the other party in…

What happens if ID tokens issued by external OpenID providers (IdP) are used for API protection? The following diagram is my understanding.

• A client that has no relationship with the resource server can access APIs of the resource server using an ID token that the client has legitimately obtained in an utterly irrelevant context.
• The user has granted a permission for the client to get an ID token, but she didn’t imagine that the permission would enable the client to call APIs of the irrelevant resource server.
• Because an ID token has no concept of scope and the aud claim holds the ID of the client (i.e., the aud claim cannot be used to restrict accessible resources as RFC 8707 proposes), possible options for API protection are just “all allowed” or “all denied”.

If I’m missing something, please correct me.

Introduction

This article explains a specification called “DPoP”, OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer.

The specification defines a mechanism to prevent illegal API calls from succeeding only with a stolen access token.

In the traditional mechanism, API access is allowed only if the access token presented by the client application is valid. However, if a mechanism of PoP (Proof of Possession) such as DPoP is employed, the API implementation additionally checks whether the client application presenting the access token is the valid owner of the access token (= whether the client application is the same one that the…

This article explains RFC 8628 (OAuth 2.0 Device Authorization Grant), a.k.a. “Device Flow”.

Device Flow is another way to issue an access token as well as the flows defined in RFC 6749 (The OAuth 2.0 Authorization Framework).

The reason for developing the new flow is described at the top of the specification as follows.

The OAuth 2.0 device authorization grant is designed for Internet-connected devices that either lack a browser to perform a user-agent-based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical.

Let’s…

This article explains “OAuth 2.0 Pushed Authorization Requests”, a new specification called “PAR”, step by step with diagrams. (Japanese version is here.)

[Additional note on Sep. 16, 2021]: PAR was promoted to RFC 9126.

1️⃣ There is a client application and an authorization server.

2️⃣ The client application has a complex authorization request.

Introduction

Act on Prevention of Transfer of Criminal Proceeds was revised in Japan on November 30, 2018. The revision has added methods to verify identities of natural persons only through online and is now regarded as the legal basis for eKYC (electronic Know Your Customer).

On November 11, 2019, about one year after the revision, OpenID Foundation, a non-profit international standardization organization, published a technical document, Implementer’s Draft 1 of “OpenID Connect for Identity Assurance 1.0”. The organization also established a new working group, “eKYC and Identity Assurance WG”, soon after the publication. …