consider methods to obtain access tokens from an authorization server instead of making them in the client

[zenomt]

in the current POP token scheme, the client directly manufactures an access token to present to the server with the "Bearer" method. as discussed on the 2019-08-26 and other calls and in #1, i believe there are numerous problems with the current POP token scheme.

several issues raised in #1 can at least be partially addressed by approaches discussed in #3, #9, #10. a summary of the most important remaining problems specifically with the client making access tokens:

• in the OAuth model, the client doesn't have standing to make the access tokens for an unrelated resource server. this right belongs to the resource server's authorization server. this may not withstand the scrutiny of security experts, and is incompatible with the kinds of security infrastructure likely to be deployed in enterprises.
• the client chooses the validity period of the access token, for which it also doesn't have standing.
  • even with add a method for the resource server to constrain the validity period of access tokens #10, there's no way for the resource server to have an access token that's valid for longer than the client proposes, which might be useful if the resource server is overloaded and wants to put off expensive (re)verification of aspects of the token, which could involve additional cryptographic and network accesses.
• the format of the access token is mandated for all Solid-compatible servers, rather than being up to the resource server's authorization server. this might make it potentially incompatible, and potentially non-optimal, with the kinds of OAuth infrastructure likely to be deployed in enterprises.
  • also these tokens are necessarily quite big and must be passed around, or at least (with HTTP/2 compression) processed in some way, on every request.

obtaining an access token from the resource server's authorization server instead of using an access token made by the client addresses the above and has the following benefits:

• the server chooses the validity period of the access token according to its security and operational requirements. the token lifetime might be shorter or longer than that proposed by the client.
  • the server can choose a validity period according to its own policy and security considerations.
  • the server can make the validity period longer than proposed by the client if the server is overloaded.
• the server can choose the format of the token to be optimal for its implementation and intended scale of operation. this could include
  • the token being a short (but "long enough") key to a database record, which is simple to implement correctly and is appropriate for a modest volume. the token can be revoked by forgetting the database record.
  • the token being an encoding of relevant information (like the webid, appid, and validitity period) signed by the server, whose presentation can be verified using on-hand information only.
    • useful in high-volume and distributed systems where storing all active tokens in a database might be infeasible.
    • since revocation is rare, it is probably feasible to remember individual revoked tokens in a table until they expire, or to revoke all active tokens by iat or serial number or something. techniques like Bloom filters could be used in very high-volume deployments.
• the multiple cryptographic and network steps involved in identity verification need only be done when new tokens are issued.
  • complex, fragile, and hard-to-get-right whole-token or intermediate verification caching strategies aren't needed for performant operation.
  • caching especially of the webid profile document might not be necessary, which can make the server more responsive to relevant changes to the profile.
• in one proposed method, a resource server + authorization server, with minimal extra attributes in a 401 response, could provide an API endpoint to obtain an access token that is otherwise compatible with the server's existing Bearer-based authorization infrastructure.
• the authorization server can support multiple methods for obtaining an access token (for example, a method using WebID-TLS as well as one based on WebID-OIDC).
• conforms to the OAuth "Bearer" model, which might make security people happier.

with the following cost:

• it requires an extra serialized HTTP transaction (to the authorization server) when a new access token is required for resources in a protection space.

[elf-pavlik]

Latest draft relies on DPoP-bound Access Token issued by user's IdP. While client doesn't create access tokens any more, just DPoP Proofs, it still doesn't follow approach suggested in this issue. Maybe we could rename this issue to clearly propose that RS associated Authorization Server should issue Access Tokens.

[elf-pavlik]

BTW maybe OAuth 2.0 Token Exchange would still allow RS to delegate some responsibilities to AS server of its choice. I guess RS would still need to do the DPoP verification but could leave all the rest to AS it exchanges tokens with.

[acoburn]

This is an old issue that has been discussed and it is more in line with classic OAuth2 than OpenID Connect. Marking as closed as the Solid-OIDC proposal relies significantly on DPoP.