Align/adopt RFC7662 token introspection and `active: true`

[jamietanna]

Just having a re-read through the access token introspection sections on the IndieAuth spec compared to OAuth2, and I noticed that IndieAuth doesn't provide the active: true field in the response, and I wondered what the thought behind that was.

Would having it as a requirement in IndieAuth also allow interactions via existing OAuth2 libraries / with minimal changes?

[Zegnat]

IndieAuth doesn’t really do any of the OAuth 2.0 Token Introspection (RFC 7662) interactions. I don’t think the token validation in IndieAuth is based on that at all, actually, though @aaronpk is the only one qualified to comment on that.

A huge difference that jumps out is that RFC 7662 requires you to POST the token you are interested in to the endpoint. Another big one is that it requires additional authentication along with the token to see whether the current requester is allowed to check a token in the first place. IndieAuth does not concern itself with either of those things.

I’d say the token endpoint in IndieAuth considers itself to also be a protected resource. When you supply a correct bearer token, the resource is returned, and that resource happens to be a JSON encoding of the data linked to your token. In my mind I compare it to being logged in to a website and viewing your own profile. You are logged in (ie. sending the bearer token) and are requesting your profile (the me associated with your session).

All that said, I do wonder if there is some argument to be made for swapping IndieAuth’s Access Token Verification for something closer to RFC 7662. Or maybe even just a small extension on RFC 7662 like how revocation is handled as an extension of RFC 7009…

[aaronpk]

Still need some investigation into OAuth library support, and experimentation can happen already given that the OAuth request is POST and IndieAuth's is GET. More notes: https://indieweb.org/2020/Pop-ups/IndieAuth#Issue_33_-_Support_OAuth2_Introspection

[jamietanna]

I have added the active path into the token verify response, as part of my new IndieAuth server, as well as adding support for an RFC7662 token introspection endpoint, too

(Originally published at: https://www.jvt.me/mf2/2020/12/n8ue5/)

[aaronpk]

• Modify access token verification section to extend Token Introspection Response to include:
  • The introspection endpoint is the same as the token endpoint.
  • The introspection response includes an additional parameter me
• In the introspection section, mention other properties that must/should be returned:
  • active, exp, iat

Find out how much the lack of authentication at the introspection endpoint is already deployed in IndieAuth systems, and decide whether to explicitly drop the authentication requirement from the introspection endpoint or require it and document how to get that credential.

[dshanske]

Just to note, the GET response returns a 400, 401, or 403 respons eto an invalid token. the introspection endpoint change would require a 200 with active: false.