Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add clarification about nonce payload and nonce endpoint security #29

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Add clarification about nonce payload and nonce endpoint security #29

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4833b19
Add clarification about nonce payload and nonce endpoint security
cmarco0 Jul 8, 2024
7fbd249
better explaination that the example provided is non-normative
cmarco0 Jul 10, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions draft-demarco-oauth-nonce-endpoint.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -105,6 +105,8 @@ Clients that utilize the Nonce Endpoint SHOULD first retrieve the Server's metad

The OAuth 2.0 Authorization Server MUST include the `nonce_endpoint` metadata in its OAuth 2.0 Authorization Server Metadata if it supports the Nonce Endpoint functionality described in this specification.

**Note:** The security and configuration of the ``nonce_endpoint`` can vary. While a standard configuration might not require client authentication, it is possible to protect this endpoint to enhance the overall security of the system.

### Example Metadata

Below is an example of how an OAuth 2.0 Authorization Server Metadata might include the `nonce_endpoint`:
Expand Down Expand Up @@ -210,6 +212,20 @@ Please note that the values represented in the previous examples are informative

In any case, the payload MUST include some unique value (`"jti"` on the example above), typically generated using a pseudo-random number generator with sufficient entropy [RFC4086], to ensure that the encrypted digest (the actual Nonce) is also unique.

# Nonce Payload Claims

The body of Nonce Payload contains:

| Claim | Description | Reference |
|-------------------|---------------------------------------------------------------------------------------------|---------------------------------|
| `jti` | A unique identifier for the token, used to prevent token reuse. | [RFC 7519, Section 4.1.7](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.7) |
| `iss` | The entity that issued the token. | [RFC 7519, Section 4.1.1](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.1) |
| `iat` | The date and time the token was issued. | [RFC 7519, Section 4.1.6](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.6) |
| `exp` | The date and time the token expires | [RFC 7519, Section 4.1.4](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4) |
| `source_endpoint` | The endpoint of the server that generated the nonce used in the token. | |
| `aud` | A list of intended recipients of the token, i.e., the services that can accept it. | [RFC 7519, Section 4.1.3](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3) |


# 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.
Expand Down