matt1097
commented
2 weeks ago I concur that machine-to-machine is effectively broken in 2024.8.3. It looks like #11537 fixed a CVE and this was a side effect.
I really would +1 your alternative approach as the better fix. Although agreed that is a lot more work. Allowing each application to opt into which applications it wants to allow into an API
Is your feature request related to a problem? Please describe.
Authentik's current implementation only allows for the introspection of tokens generated with the provider used to authenticate against the introspection endpoint.
This is an issue because the resource server is then required to use the same provider as the client and it prevents the use of multiple providers, each with their own client_id (let's say Thunderbird, Roundcube and mutt) to access a resource server (a Dovecot server for instance).
Describe the solution you'd like
See #11617
Remove the provider filter when retrieving tokens.
Additionally to prevent token fishing from public applications, I believe that restricting the introspection endpoint to confidential clients would be beneficial (and one could argue that a public client does not satisfy RFC7662 requirements for authentication).
Because of issue #11616 I don't think it is likely that preventing public clients from using the introspection endpoint will cause much harm.
Describe alternatives you've considered
Instead of allowing the introspection of all tokens, a per-provider option or scope (as described here for instance) could be an alternative, albeit one requiring more involvement.