Directed Access Tokens

An AS should be able to tell a client the ways in which it can use an access token. Beyond limiting the rights in the token, which is enforced by the RS, the AS should be able to indicate to the client the actions that it can successfully and safely take with the token itself.

These directions could include:

• Which URLs the token is good at (maybe URI templates or patterns, to allow for full API access)
• Which HTTP verbs the token can be used for
• Which headers are required or forbidden
• If query parameters are allowed to be added or removed

This list is HTTP specific but similar constraints would be warranted for other non-HTTP protocols if those arise in the future.

Each set of directions should be able to be combined with others, so that you can say "do a GET on URL A but a POST on URL B and not the other way around".

This should not cause any extra burden on clients that are pre-programmed to use their access tokens in a particular way, and it should not be a security leak for a client to ignore this direction (ie, the RS should enforce this even if the client gets it wrong).

See also Resource Discovery.