Introduction

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

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


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.

Image for post
Image for post

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

Image for post
Image for post
  • 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.

Image for post
Image for post

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.

Image for post
Image for post

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…


Introduction

Financial-grade API (FAPI) is a technical specification that Financial-grade API Working Group of OpenID Foundation has developed. It uses OAuth 2.0 and OpenID Connect (OIDC) as its base and defines additional technical requirements for the financial industry and other industries that require higher security.

Image for post
Image for post
OpenID Foundation Working Groups and Financial-grade API stack

The latest version is Implementer’s Draft 2 which was approved in October, 2018. Part 1 and Part 2 are freely viewable at the website of OpenID Foundation. Part 1 is a security profile for read-only APIs, and Part 2 is a security profile for read-and-write APIs.

Takahiko Kawasaki

Co-founder and representative director of Authlete, Inc., working as a software engineer since 1997. https://www.authlete.com/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store