...

1. Put a valid identifier, (e.g. username) in the userId header (just like API keys)

2. Put the token in the Authorization header with the ‘Bearer’ keyword preceding the token (Authorization: Bearer <token>)

Open Questions

Which of these services be accessible via scoped access tokens?

• I think by default, creating/deleting should not be accessible at all. If a use case comes up, then these can be accessible via the authorize scope. Viewing the list of tokens can be done with the view scope.

What should the token look like? Some options

• Opaque token

  • With or without additional userId header?

• Non-expiring JWT (containing a token ID and a user ID)

This is partially an implementation question. The ability to revoke tokens requires storing tokens or token identifiers in persistent storage. Performance is critical because a lookup will be done for every authenticated request made by a programmatic client.