[spec] Auth: Token validation #408
Conversation
pcarleton
changed the title
|
I personally think it would be helpful to force client to send audience while requesting for a token so that the access token generated can be linked to a specific RS. |
RFC 8707 is only one way the AS can audience restrict tokens. It is a good option, but there are other ways to solve it as well, such as defining scopes per resource server. For example, if the client requested the scope |
Co-authored-by: Aaron Parecki <[email protected]>
Co-authored-by: Aaron Parecki <[email protected]>
D-McAdams
left a comment
D-McAdams
left a comment
There was a problem hiding this comment.
This topic is more verbose than other security considerations and duplicates requirements from other specifications. For example, recommend that we don't list token validation options as these are defined in OAuth 2.1 - Section 5.2
In some places, it also conflicts with specifications. For example, it asserts that MCP Servers MUST strictly validate token audiences, but this only applies to RFC 9068 (JWT Tokens). Opaque tokens don't have an audience field available - they are validated via token introspection.
The intent appears to be to discourage token passthrough by reminding parties of the restrictions in the specifications. It should be possible to achieve this with fewer lines. See suggested short version in comments.
|
Regarding @aaronpk and @0Itsuki0 's points on RFC 8707 above, the scope-based audience restriction would work for preventing valid Resource Server (RS) token misuse, but not for a malicious RS, right? I'm thinking about the case listed in @aaronpk 's RFC here. Could theoretically be solved by listing valid RSs in the Authorization Server Metadata (ASM) as described in PRM but only if the RSs are enumerable. Wonder if it's worth including this somehow. |
Since this is an optional property, I wonder if 3rd party authorization server actually include this in their ASM...If not then enforcing AS to include this property would basically make whoever implemented the RS to make the AS as well... |
|
@allenzhou101 @0Itsuki0 without being too verbose, I added a reference to RFC 8707 at the end of the section. |
|
I am on board with moving the bulk of the explanation lower down like this. |
Co-authored-by: Aaron Parecki <[email protected]>
Motivation and Context
Split from #387 to allow for longer discussion without holding up the section shuffle
Previous discussion:
#387 (comment)