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.
JAR is a mechanism whereby to pack authorization request parameters into a signed JWT. …
This article explains X.509 certificate.
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.
audclaim holds the ID of the client (i.e., the
audclaim 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.
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.
1️⃣ There is a client application and an authorization server.
2️⃣ The client application has a complex authorization request.
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.
There is an authorization server.
There is a client application that wants to get an access token from the authorization server.
It depends on each authorization server how to implement access tokens.
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.
In an identifier-type implementation, information associated with access tokens is stored in a database…
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.
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.