oauth2.dev

PoP

IETF

Registry Context

PoP identifies a proof-of-possession access token bound to a cryptographic key. The client demonstrates possession of that key when making an authorized request, and the resource server verifies that the demonstrated key matches the token binding.

Technical Summary

RFC 9200 registers PoP with cnf and rs_cnf as additional token endpoint response parameters and no HTTP authentication scheme. ACE profiles specify how proof of possession is performed. PoP keys may use symmetric or asymmetric cryptography.

When Used

Used by ACE-OAuth deployments where access-token use must demonstrate possession of a bound key rather than rely only on possession of the token.

Normative Requirements

Clients

MUST NOT
1

  1. RFC 6749 - Section 7.1

    Use an access token whose token type it does not understand..

    Condition: When deciding whether to use an access token.

    The client MUST NOT use an access token if it does not understand its type.

Authorization servers

MUST
2

  1. RFC 9200 - Section 6.1

    Encrypt a symmetric PoP key contained in an access token so that only the resource server can decrypt it..

    Condition: When an access token contains its symmetric PoP key.

    The symmetric key MUST be encrypted by the authorization server.

  2. RFC 9200 - Section 6.1

    Protect the token with an asymmetric signature..

    Condition: When the token is intended for multiple recipients.

    A token with a multirecipient audience MUST use an asymmetric signature.

REQUIRED
1

  1. RFC 9200 - Section 5.8.2

    Include the token_type parameter..

    Condition: When a specific use case requires a token type other than PoP.

    For a use case requiring another token type, token_type is REQUIRED.

SHOULD
1

  1. RFC 9200 - Section 6.1

    Scope the access token to a specific permission..

    Condition: When binding a symmetric key to an access token.

    Authorization servers SHOULD scope such tokens to a specific permission.

Resource servers

MUST
3

  1. RFC 9200 - Section 5.10.2

    Verify that it has an access token authorizing the request and that the client performed the token's proof-of-possession binding to the request..

    Condition: When the requested resource requires authorization.

    The resource server MUST verify both authorization and proof-of-possession binding.

  2. RFC 9200 - Section 5.10.2

    Return 4.01 Unauthorized..

    Condition: When the client has not performed proof of possession or the resource server has no valid access token for the client.

    The response code MUST be 4.01 in either case.

  3. RFC 9200 - Section 6.2

    Use confidentiality protection for communication with the authorization server..

    Condition: When communicating with the authorization server.

    Communication with the authorization server MUST use confidentiality protection.

ACE implementation

MUST
1

  1. RFC 9200 - Section 6.1

    Apply integrity protection to the access token..

    Condition: When issuing or protecting an ACE access token.

    Token integrity protection MUST be applied.

SHOULD
1

  1. RFC 9200 - Section 5.8.2

    Assume that token_type is PoP when token_type is omitted..

    Condition: When processing an ACE authorization-server response without token_type.

    Implementations SHOULD assume that token_type is PoP by default.

ACE profile

MUST
5

  1. RFC 9200 - Section 5.8.4.2

    Specify how the client proves possession to the resource server..

    Condition: When defining use of PoP access tokens.

    The proof of possession procedure MUST be specified by profiles.

  2. RFC 9200 - Section 5.8.4.3

    Define the communication protocol and communication security protocol between the client and resource server..

    Condition: When defining an ACE profile.

    Profiles MUST define both protocols.

  3. RFC 9200 - Section 5.8.4.3

    Use a client-to-resource-server security protocol that provides encryption, integrity, and replay protection..

    Condition: When defining an ACE profile.

    The security protocol MUST provide encryption, integrity, and replay protection.

  4. RFC 9200 - Section 5.8.4.3

    Use a client-to-resource-server security protocol that binds requests to responses..

    Condition: When defining an ACE profile.

    The security protocol MUST provide request-response binding.

  5. RFC 9200 - Section 5.8.4.3

    Define the allowed proof-of-possession methods..

    Condition: When the profile supports PoP access tokens.

    Profiles MUST define allowed proof-of-possession methods when supporting PoP tokens.

Authorization server or deployment

MUST NOT
1

  1. RFC 9200 - Section 6.1

    Use the same shared secret as a proof-of-possession key with multiple resource servers..

    Condition: When symmetric PoP keys are used.

    The same shared secret MUST NOT be used with multiple resource servers.

Protocol implementation

MUST
1

  1. RFC 9200 - Section 5.8.4.2

    Use registered CBOR abbreviations for token_type values..

    Condition: When token_type is encoded using CBOR.

    token_type values MUST use the registered CBOR abbreviations.

Validation Guidance

warning

When token_type is absent in an ACE token response, verify that the implementation defaults it to PoP unless a documented exception justifies departing from the SHOULD.

error

When a non-PoP token type is used, verify that the authorization-server response includes token_type.

error

For CBOR responses, verify that token_type uses its registered CBOR abbreviation.

error

Confirm that the selected ACE profile defines the PoP procedure, allowed PoP methods, and protected client-resource-server communication, including request-response binding.

error

Before accepting an authorized request, verify both token authorization and proof-of-possession binding; return 4.01 when proof is absent or no valid token is available.

error

Verify access-token integrity protection, encryption of any symmetric PoP key contained in the token, and asymmetric signing for multirecipient tokens.

error

Prevent reuse of one symmetric PoP secret across multiple resource servers.

warning

Check that access tokens bound to symmetric keys are scoped to a specific permission unless a documented exception justifies departing from the SHOULD.

error

Verify confidentiality protection for communications with the authorization server.

error

Reject use of a PoP access token when the client does not understand the token type.

info

Recognize cnf and rs_cnf as the additional token endpoint response parameters registered for PoP; this registration lists no HTTP authentication scheme.

Security Notes

RFC 9200 - Section 3.1

PoP security depends on the resource server verifying that the key demonstrated by the client matches the key bound to the access token.

RFC 9200 - Section 6.1

Access-token integrity protection prevents modification of authorization data, including the reference to the PoP key.

RFC 9200 - Section 6.1

A symmetric PoP key contained in a token must be encrypted so that only the resource server can decrypt it.

RFC 9200 - Section 6.1

Reusing a symmetric PoP secret across resource servers reduces the security benefit of proof of possession.

RFC 9200 - Section 6.2

Exposing a PoP key or access token during communication with the authorization server can negate proof-of-possession security.

RFC 9200 - Section 6.2

An attacker who obtains the private or symmetric PoP key can impersonate the client.

Reference

RFC9200

Details

Entry Id
PoP
Name
PoP
Additional Token Endpoint Response Parameters
cnf, rs_cnf (see section 3.1 of RFC8747 and section 3.2 of RFC9201).
Http Authentication Scheme
N/A
Change Controller
IETF
Reference
RFC9200