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.)

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. …

This article explains “OAuth 2.0 client authentication”.

In addition to the client authentication methods described in RFC 6749, this article explains methods that utilize a client assertion and a client certificate.

1. Client Authentication Methods

1.1. Token Endpoint

There is an authorization server.

There is a client application that wants to get an access token from the authorization server.

1. Implementation Types

It depends on each authorization server how to implement access tokens.

It depends, but as the description in “1.4. Access Token” of RFC 6749 implies as follows,

The token may denote an identifier used to retrieve the authorization information or may self-contain the authorization information in a verifiable manner (i.e., a token string consisting of some data and a signature). …

implementations can be categorized into two major patterns, that is, “identifier type” and “self-contained type”. There also exists “hybrid type” that combines the two types.

1.1. Identifier Type

In an identifier-type implementation, information associated with access tokens is stored in a database…