Authenticated Requests

[jankapunkt]

An authorization server may bind tokens to a certain client
identifier and enable resource servers to validate that association
on resource access. This will require the resource server to
authenticate the originator of a request as the legitimate owner of a
particular token. There are several options to implement this
countermeasure:

o The authorization server may associate the client identifier with
the token (either internally or in the payload of a self-contained
token). The client then uses client certificate-based HTTP
authentication on the resource server's endpoint to authenticate
its identity, and the resource server validates the name with the
name referenced by the token.

o Same as the option above, but the client uses his private key to
sign the request to the resource server (the public key is either
contained in the token or sent along with the request).

o Alternatively, the authorization server may issue a token-bound
key, which the client uses in a Holder-of-Key proof to
authenticate the client's use of the token. The resource server
obtains the secret directly from the authorization server, or the
secret is contained in an encrypted section of the token. In that
way, the resource server does not "know" the client but is able to
validate whether the authorization server issued the token to that
client.

Authenticated requests are a countermeasure against abuse of tokens
by counterfeit resource servers.