Issuing Access Tokens for Introspection

[dshanske]

#33 and related PR #94 cover the issue of changing the token verification request to align with the Token Introspection spec. The decision to adopt this, and a specific definition that requires the issuance of credentials to access the token introspection endpoint requires the discussion of an out of band method to issue those credentials, which would take the form of a separate access token.

To quote @aaronpk #94 (comment), "Basically it means that when I build a service like Aperture, which is going to be validating access tokens from the user's own AS that they bring, I need to add a step in the signup flow that asks them to create an access token specifically for Aperture that can be used to validate access tokens. I like that because it means the user has some understanding that they are turning Aperture into part of their own website rather than it being something more decentralized, since in reality it is a service I am running for people. Later we can talk about how to automate the issuing of tokens like these, which would be another OAuth flow and probably some new scopes to add to a spec."

This is the place to discuss this matter in future.

[jamietanna]

As per mention on #94, I believe this would be credentialed either through HTTP Basic, or an access token issued by some client_credentials grant.

I would personally recommend private_key_jwt as it allows easier, seamless rotation of credentials, but plain client_secret_basic or client_secret_post would be sufficient for most use cases

[dshanske]

When I wrote the PR, I proposed specifically the access token path. But, client_credentials would be consistent. However, IndieAuth has no concept of client_secret and expressly states all clients are public. So there might have to be a flow initiated by the owner of the resource server to get them the access token.

[jamietanna]

True - IndieAuth clients are public. But a Resource Server would not be quite like "regular" IndieAuth client, and would instead be safe to be credentialed

[dshanske]

I think we have more discussion before we come to a conclusion

[jamietanna]

Per #94 (comment) and #94 (comment) consensus is that this is credentialed.

We should still look at suggestions for how this is managed 👍

[jamietanna]

I wonder if issuing credentials could be done using Ticket Auth 🤔 it allows the Resource Owner to tell a remote Resource Server that yes, you can access this set of resources

[omz13]

If the introspection endpoint needs some assurance that the client is genuine, probably the easiest thing to do is include the code_verifier in the request (in the body ideally or less ideally somehow mangled into an Authorization header) so the AS can reconcile the token and code_verifier before yielding a response.

^^^ also applies to revocation

and see especially the note in https://www.rfc-editor.org/errata/rfc7009