OAuth Proof of Possession Tokens with HTTP Message Signatures

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 2 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The OAuth 2.0 framework provides methods for clients to get delegated access tokens from an authorization server for accessing protected resources. The access tokens at the center of OAuth 2.0 can be bound to a variety of different mechanisms, including bearer tokens, mutual TLS, or other presentation mechanisms.¶

Bearer tokens are simple to implement but also have the significant security downside of allowing anyone who sees the access token to use that token. [HTTPSIG] defines a generic mechanism that is used to sign HTTP requests and responses.¶

This specification defines means to bind access tokens to a key held by the client, a token type value and token response for indicating that a token is meant to be used with [HTTPSIG] presentation, and a method for presenting bound access tokens in HTTP requests using [HTTPSIG].¶

This work complements and builds on experience with [DPOP] and [MTLS], as well as implementations of [I-D.ietf-oauth-signed-http-request], a spiritual predecessor to this specification and other forms of OAuth proof-of-possession work.¶

[[ Editor's note: we want to give developers clear guidance on when to use HTTPSig vs. DPoP vs. mTLS vs. Bearer vs. whatever else ]]¶

2. Requesting an HTTP Message Signature Bound Access Token

To bind an access token to a key, the AS needs to know which key to bind to which token. This specification defines two common methods depending on the needs of the client:¶

• A static method that depends on key material available as part of the client registration¶

• A runtime method that allows a client to introduce key material during the token request phase of [OAUTH]¶

As part of its registration, a client MUST indicate which method it will use.¶

[[ Editor's note: do we want to add a client metadata parameter to signal this, as well as an AS/RS metadata parmaeter to signal support for each type? ]]¶

[[ Editor's note: Are there any other patterns of key introduction we should cover? I put PAR in the appendix as a note. ]]¶

{
    "kty": "OKP",
    "use": "sig",
    "crv": "Ed25519",
    "kid": "j-0Ny45NWmqGq6GQ",
    "x": "iuemcj_GhRHmY_yCsMlDNp3BQgPZDdG00VRsg_BgU3s",
    "alg": "EdDSA"
}

NOTE: '\' line wrapping per RFC 8792

Signature-Key: :eyJrdHkiOiJPS1AiLCJ1c2UiOiJzaWciLCJjcnYiOiJFZDI1NTE5I\
  iwia2lkIjoiai0wTnk0NU5XbXFHcTZHNFV4TGpHak51bG9rdHVndE9XNGpmR0NDZ2Vm\
  USIsIngiOiJpdWVtY2pfR2hSSG1ZX3lDc01sRE5wM0JRZ1BaRGRHMDBWUnNnX0JnVTN\
  zIiwiYWxnIjoiRWREU0EifQ==:

NOTE: '\' line wrapping per RFC 8792

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA\
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Content-Digest: sha-256=:4fEzRVTGqfZg7lqf/d3oxXu837pvb3L0GN24+F1VkZk=:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
Signature-Key: :eyJrdHkiOiJPS1AiLCJ1c2UiOiJzaWciLCJjcnYiOiJFZDI1NTE5I\
  iwia2lkIjoiai0wTnk0NU5XbXFHcTZHNFV4TGpHak51bG9rdHVndE9XNGpmR0NDZ2Vm\
  USIsIngiOiJpdWVtY2pfR2hSSG1ZX3lDc01sRE5wM0JRZ1BaRGRHMDBWUnNnX0JnVTN\
  zIiwiYWxnIjoiRWREU0EifQ==:
Content-Digest: sha-256=:4fEzRVTGqfZg7lqf/d3oxXu837pvb3L0GN24+F1VkZk=:
Signature-Input: sig1=("@method" "@target-uri" "content-digest" \
  "signature-key" "authorization");created=1618884473\
  ;keyid="j-0Ny45NWmqGq6G4UxLjGjNuloktugtOW4jfGCCgefQ"\
  ;nonce="b3k2pp5k7z-50gnX1b06";tag="httpsig-oauth-token-request"
Signature: sig1=:AWyxebrJ6u8CMi0B3TyX9G1G3XT45UW5zIn8mhsyXdmjTUtGS+1M\
  XiydKv5z0GLCrMhVSFe691jF98DRNNSPAg==:

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&\
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

3. Issuing an HTTP Message Signature Bound Access Token

The AS MUST validate the signature of the token request sent in Section 2.3 against the identified key and the algorithm associated with that key.¶

The request MUST fail with an error if any of the following occur:¶

• The key named in kid cannot be found or is not associated with the requesting client¶

• There is more than one signature with the tag "httpsig-oauth-token-request"¶

• The created value of the signature is too far in the past¶

• The nonce value is used more than once within the validity window of the signature¶

When issuing an access token bound to a key using HTTP Message Signatures, the AS associates the granted token with the key used in the requesting signature. All presentations of this token at any RS MUST contain an HTTP message signature as described in Section 4.¶

An HTTP Message Signature bound access token MUST have a token_type value of httpsig.¶

HTTP 200 OK
Content-Type: application/json

{
    "access_token": "2340897.34j123-134uh2345n",
    "token_type": "httpsig"
}

The client MUST associate this returned access token with the key used to make the requst.¶

[[ Editor's note: we should define confirmation methods for access tokens here, including JWT values and introspection response values to allow the RS to verify the signature w/o the client's registration information. Leaving the following sections as placeholders. ]]¶

4. Presenting an HTTP Message Signature Bound Access Token

HTTP Message Signature bound access token MUST be presented in an HTTP Authorization field using the HTTPSig authorization scheme.¶

Authorization: HTTPSig 2340897.34j123-134uh2345n

Note that HTTP authorization schemes defined in [HTTPAUTH] are case-insensitive, and so all the following are equivalent:¶

Authorization: HTTPSig 2340897.34j123-134uh2345n
Authorization: httpsig 2340897.34j123-134uh2345n
Authorization: HTTPSIG 2340897.34j123-134uh2345n
Authorization: Httpsig 2340897.34j123-134uh2345n
Authorization: hTpTsIg 2340897.34j123-134uh2345n

When presenting an HTTP Message Signature bound access token to an RS, the client MUST include a signature compliant with [HTTPSIG]. The covered components MUST include:¶

• @method the HTTP method of the request¶

• @target-uri the full request URI of the request (note that this includes the scheme, authority, path, and query)¶

• authorization the access token value being presented¶

The RS MAY require additional components to be covered by the signature, and the client MUST include any additional fields or components of the HTTP request that are relevant to the security of the RS. For example, if the API being served by the RS declares that incoming content type makes a material difference, the RS SHOULD require signing of the Content-Type header in addition to the above.¶

The request MAY include multiple signatures to serve different needs.¶

If the request includes an entity body (such as a POST, PUT, or QUERY), the client SHOULD calculate the digest as per [DIGEST] and also sign the digest header (such as Content-Digest).¶

The signature MUST include the following parameters:¶

• created a timestamp for signature creation; this MUST be within a small number of seconds of issuance (e.g. 30 seconds to account for clock skew)¶

• nonce a random unique value that the AS can use to prevent signature replay within the small validity time window¶

• tag a string indicating that this is being used for requesting a bound token, MUST be the value "httpsig-oauth"¶

• keyid the kid value for the key used to sign the request¶

The client MUST NOT include an alg signature parameter.¶

For example, the following signed request includes a signature with the needed parameters:¶

NOTE: '\' line wrapping per RFC 8792

GET /foo HTTP/1.1
Host: example.com
Date: Mon, 20 Apr 2026 02:07:55 GMT
Authorization: HTTPSig 2340897.34j123-134uh2345n
Signature-Input: sig1=("@method" "@target-uri" "authorization")\
  ;created=1776650875;keyid="j-0Ny45NWmqGq6G4UxLjGjNuloktugtOW4jfGCCg\
  efQ";nonce="k9Jyxempel2305Nmx7Rk";tag="httpsig-oauth"
Signature: sig1=:kFJC2WoBbrQc8tsKiowIb8oeIA533qmKvzdKf8kndJ7kaLxGmm2v\
  9+IPB8kLE0WUea8KryJGSV7ji1apLkeKBg==:

5. Validating an HTTP Message Signature Bound Access Token Request

In order for a request protected by an HTTP Message Signature bound access token to be considered valid, the RS MUST perform the following checks:¶

• The presented signature validates using the key associated with the token¶

• The signature validates using the algorithm associated with the key¶

• The created value is not too far in the past (e.g. 30 seconds to account for clock skew and network delays)¶

• The nonce value has not been previously used within the time validity window of this request¶

• The tag value is "httpsig-oauth"¶

• The covered components and parameters include all items enumerated in Section 4¶

If the request includes an entity body (such as a POST, PUT, or QUERY) and a digest as per [DIGEST], the RS MUST validate the digest.¶

If the request includes multiple signatures tagged "httpsig-oauth", all signatures MUST be validated.¶

For example, to validate the request:¶

NOTE: '\' line wrapping per RFC 8792

GET /foo HTTP/1.1
Host: example.com
Date: Mon, 20 Apr 2026 02:07:55 GMT
Authorization: HTTPSig 2340897.34j123-134uh2345n
Signature-Input: sig1=("@method" "@target-uri" "authorization")\
  ;created=1776650875;keyid="j-0Ny45NWmqGq6G4UxLjGjNuloktugtOW4jfGCCg\
  efQ";nonce="k9Jyxempel2305Nmx7Rk";tag="httpsig-oauth"
Signature: sig1=:kFJC2WoBbrQc8tsKiowIb8oeIA533qmKvzdKf8kndJ7kaLxGmm2v\
  9+IPB8kLE0WUea8KryJGSV7ji1apLkeKBg==:

The RS determines the key bound to the token and validates the kid value against that key. The RS determines the algorithm from the key and performs signature validation per [HTTPSIG] on the¶

In this example, the client has a key with the kid value of test-key-rsa-pss which uses the JWA alg value of PS512. The signature input string is:¶

"@request-target": get /foo
"host": example.org
"authorization": HTTPSig 2340897.34j123-134uh2345n
"@signature-params": ("@request-target" "host" "authorization")\
  ;created=1618884475;keyid="test-key-rsa-pss"

This results in the following signed HTTP message, including the access token.¶

NOTE: '\' line wrapping per RFC 8792

GET /foo HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Authorization: HTTPSig 2340897.34j123-134uh2345n
Signature-Input: sig1=("@request-target" "host" "authorization")\
  ;created=1618884475;keyid="test-key-rsa-pss"
Signature: sig1=:o+Fy/a6IIWhHwnMFhsHqfXEpheWGBMOU3pheT50zA8rL5F8Nur\
  xBKAPylMGBWYCKH5Bd+TB0Co6vqANlXyOCM9Zr5c/UmR5WGex5/OgJJmfN7gOVOH5\
  pB2Zxa233xsohfwo9liBlctukN5//E3F04rKjIkoeTFJiS+hMcOzn29esgFSEl4Jy\
  oO5Q8snMIsC56ZAPYwU7rJis1Wvl6Y9/9tpW6gIn/SHwArhPQSAb0zZy6mCiw654n\
  CaKw5NYJ9S0DZlnV4T7nJtdZsHOkddF6kH4WVka3ev0xONI5kYkEdR1Gw0VAE9thi\
  p+3/aFoUVTJ/1J6JfehZpXqehwv3KNoQ==:

An RS receiving such a signed message and a bound access token MUST verify the HTTP Message Signature as described in [HTTPSIG]. The RS MUST verify that all required portions of the HTTP request are covered by the signature by examining the contents of the signature parameters.¶

6. Acknowledgements

7. IANA Considerations

[[ TBD: register the token type and new parameters into their appropriate registries, as well as the JWT and introspection parameters needed for confirmation methods. ]]¶

8. Security Considerations

[[ TBD. ]]¶

• All requests have to be over TLS or equivalent as per [BCP195].¶

• Leakage of a private key alongside a token allows for re-presentation of that token.¶

• Insufficient coverage of a message allows a signature to be attached to a different message.¶

• Failure to check derived attributes allows a signature to be replayed.¶

• Signatures could be replayed outside of their vailidty window if not checked.¶

9. Privacy Considerations

[[ TBD. ]]¶

• Re-use of a public-key for tokens at multiple RS's can allow tracking of a client/user combination based on the key identity.¶

10. References

Appendix A. Document History

• -01¶

  • Added key binding semantics¶

  • Updated references¶

  • Updated presentation requirements¶

  • Added appendix for potential future work¶

  • Added some basic security and privacy considerations, to be expanded upon group discussion¶

• -00¶

  • Initial individual draft.¶

Appendix B. Potential Other Work

[HTTPSIG] provides a generic mechanism for signing arbitrary HTTP messages, both requests and responses. While this specification is focused solely on OAuth access token issuance and usage, [HTTPSIG] could be used in other places in the OAuth ecosystem and this appendix exists to capture some of those ideas.¶

Author's Address