OAuth 2.0 Nonce Endpoint draft 00 読書感想文

はじめに

なんか OAuth 2.0 Nonce Endpoint という仕様が公開されていました。とりあえずざっくりと読んでみたので感想を備忘録として残してみます。

https://www.ietf.org/archive/id/draft-demarco-nonce-endpoint-00.html

Abstract

OAuth 2.0 に Nonce Endpoint を定義する仕様とのことです。Authorization Server が opaque な nonce を生成および発行する方法と、Client がこのエンドポイントから nonce を取得する方法について説明されているそうです。

This document defines the Nonce Endpoint for OAuth 2.0 implementations [RFC6749]. It details how an Authorization Server generates and issues opaque Nonces and how a client can learn about this endpoint to obtain a Nonce generated by the Authorization Server.

1. Introduction

大体 Abstract と同じことが記載されているようです。

This specification presents a comprehensive guide to the Nonce endpoint in OAuth 2.0 implementations [RFC6749]. It describes in detail how a client can request and receive a server-generated Nonce, which is a unique, one-time use, opaque string. This document provides in-depth insights into the cryptographic methods used in generating Nonces to protect the confidentiality of the information associated with them.

OAuth 2.0 を使用しながらシステムの scalability、security、efficiency を強化するみたいなことが書いてあって気になります。

In addition, it is a great resource for developers and system architects who desire to strengthen the scalability, security, and efficiency of their systems while using OAuth 2.0.

2. Conventions and Definitions

割愛

3. Terminology

Nonce はリプレイアタック対策の一度のみ使用可能な値ということです。
また、見慣れない用語があります。Nonce Issuer は通常 Authorization Server　になり、Nonce Endpoint も Authorization Server のエンドポイントになりそうです。

Nonce:
A random or pseudo-random number that is generated for a specific use, typically for cryptographic communication. The Nonce is used to protect against replay attacks by ensuring that a message or data cannot be reused or retransmitted. The term "Nonce" stands for "number used once" and it MUST be unique within some scope.

Nonce Issuer:
The entity that generates and provides the Nonce. In the context of OAuth 2.0, the Nonce Issuer would typically be the Authorization Server.

Nonce Endpoint:
The HTTP endpoint provided by the Nonce Issuer for the issuance of the Nonces.

4. Requirements

Nonce Endpoint、Nonce、Nonce Issuer、Nonce の audience それぞれの要求事項について記載があります。個人的に特に気になる点はありません。細かいことは時が来たら見れば良い気がします。

The Nonce Endpoint MUST satisfy the following requirements:
・Employ TLS for securitung the Endpoint [RFC5246].
The Nonce MUST satisfy the following requirements:
・Pure opacity to recieving Clients.
The Nonce Issuer MUST satisfy the following requirements:
・Generate a unique Nonce for each request to ensure the Nonce Issuer never produces identical Nonces, regardless of whether they occur simultaneously or at different times;
・Encrypt the Nonce with an encryption key that:
・MUST NOT supplied by the Nonce Issuer to the Client;
・MUST NOT disclosed by the Nonce Issuer to any external entity beyond its domain.
The audiences of the Nonces satisfies the following requirements:
The servers, within the Nonce Issuer's domain, SHOULD decrypt the Nonce and access its decrypted contents. No other entity might decrypt or know the decrypted contents of the Nonce.

5. Nonce Request

リクエストの例はこんな感じらしいです。特に言うことはありません。

GET /nonce HTTP/1.1
Host: server.example.com

6. Nonce Response

レスポンスの例はこんな感じらしいです。こちらも特に言うことはありません。

HTTP/1.1 200 OK
Content-Type: application/json

{
  "nonce": "d2JhY2NhbG91cmVqdWFuZGFt"
}

7. Nonce Endpoint Discovery

Authorization Server が特定のリソースのリクエストに Nonce を要求するにもかかわらず Client がリクエストで Nonce を提供しない場合などのレスポンスについて記載されています。
例えば、ステータスコード 400 で nonce_required というエラーを返しつつレスポンスヘッダー Nonce-Endpoint-URI で Nonce Endpoint を伝えるみたいなことが記載されています。

HTTP/1.1 400 Bad Request
Nonce-Endpoint-URI: https://server.example.org/nonce-endpoint

{
  "error": "nonce_required",
  "error_description":
    "Authorization server requires the nonce in the request"
}

そのほかにも状況に応じた細かい動作について記載があります。

In cases where, for some reasons, a correctly issued Nonce can no longer be considered valid by the Authorization Server that receives it, the Authorization Server MUST return the generic error "nonce_required" reporting the same description as "error_description", as if the Nonce had not been received. The cases when an issued Nonce is considered no longer valid MAY be caused by the rotation of the encryption keys, its expiration or other specific conditions internal to an implementation.

8. Non-normative Examples of a Nonce Payload

復号された Nonce ペイロードは様々なフォーマットやエンコーディングを使用することができ、お馴染みの iat、exp、aud などの claim が含まれるとのことです。
以下は JSON serialized の Nonce ペイロードの例とのことです。

{
  "iss": "https://server.example.org",
  "iat": 1615908701,
  "exp": 1615995101,
  "source_endpoint": "https://server.example.org/nonce-endpoint",
  "aud": [
    "https://service.example.com/endpoint",
    "https://another.example.com/cb"
  ]
}

そもそも encrypt についてや、exp や iat を除いてランダムな値をペイロードに含めなければならないみたいな Issue もあがっています。

• What does encrypt mean?
• payload must include a random value

現時点であんまり深く考えてもという気がしますが、Nonce は何かしらの方法で暗号化やエンコードされた値も使用されることがこれまでの内容からも示唆されているといった感じですかね。

9. Security Considerations

Security Considerations について割と細かく記載がありますが、特に目新しいようなものは見受けられない気がするので割愛します。

The Nonce Endpoint MUST be protected by TLS to prevent eavesdropping and man-in-the-middle attacks, therefore the practices defined in [BCP195] should be followed.

The Nonce Issuer MUST securely generate and store the encryption key used to encrypt the Nonce. The robustness of the encryption key plays a crucial role in the security of the Nonce Endpoint. The following considerations MUST be taken into account:
...

10. Considerations about Nonce vs. jti

jti claim と Nonce の違いを説明してくれるらしいです。

This section provides some thought about the main differences and scopes of the Nonce in compared to the jti claim defined in [RFC7519].

jti と Nonce はどちらもリプレイアタック対策に使用されるが、Nonce の方が実装の柔軟性が高くベストプラクティスとみなされるらしいです？
例えば、Nonce はステートレスで作成および管理ができるという点が挙げられています。

Both jti and Nonces are used to prevent replay attacks, however Nonces offer more implementation flexibility and are considered best practice. They can be created and managed stateless (e.g., by issuing the hmac over the current time as the Nonce), as this document outlines.

細かい違いについては以下の通りとのことです。

The main differences between the use of the jti and the Nonces can be summarized as follows:

1. Generation: Nonces are generated by the server, while jti is generated by the Client.
2. Storage: Nonces can be self-authenticating and self-contained and therefore need not be stored. A common way to achieve this is for the Nonce to contain content encrypted to the Authorization Server that creates it. On the other hand, checking jti properly definitely requires a store that is shared across all domains that the associated JWT can be presented in.
3. Lifetime: The life span difference between a Nonce and a jti is significant. Nonces are kept just until the Client responds, which happens practically immediately after they are obtained, resulting in a very short lifespan. A jti, on the other hand, must be stored until the expiration window of its associated JWT expires, which is a substantially longer length than that of a Nonce.
4. Security: Nonces prevent replay attacks by ensuring that the proof of possession is fresh. On the other hand, jti does not guarantee freshness and using client-generated timestamps has problems, even for non-attacking Clients (e.g. devices with incorrect time-zones or daylight saving settings).

11. IANA Considerations

割愛

12. References

割愛

おわりに

そうえいば、Authorization Server が Nonce を発行するみたいなユースケースに関しいえば、"OAuth 2.0 Demonstrating Proof of Possession (DPoP) | 8. Authorization Server-Provided Nonce " といったユースケースがあったこと思い出しました。
一方で、現時点ではこの仕様を使いたいユースケースがどのくらいあるのかなあという印象持ち、もう少しモチベーションあたりが知りたかったなと思いました。

ではまた！