2021/Pop-ups/IndieAuth

From IndieWeb

IndieAuth 2021 was an IndieWebCamp Pop-ups 2021 session held 2021-08-28.

Summary

It's been a year since the last IndieAuth protocol session. This popup IndieWebCamp session will focus on discussions to iterate and evolve the IndieAuth protocol.

Details

Possible Topics

Discussed

  • Adding editorial notations to the spec regarding token lifetime, expiration and refresh tokens, to reference the OAuth2 specifications on this, and any specific considerations for IndieAuth. https://github.com/indieweb/indieauth/issues/81
  • Deprecate / remove the IndieAuth token verify endpoint, requiring IndieAuth servers to align with RFC7662 for OAuth2 Token Introspection
  • Make IndieAuth token verify endpoint credentialed, so it is clear that this should only be used by Resource Servers
  • Clarification on issuing tokens with only profile scopes. https://github.com/indieweb/indieauth/issues/62
  • Allow clients to always exchange authorization codes at the token endpoint https://github.com/indieweb/indieauth/issues/58

Notes

Possible topics are visible at https://indieweb.org/2021/Pop-ups/IndieAuth.

  • https://github.com/indieweb/indieauth/issues/81 and expiry:
  •   Jamie Tanna would like to discuss "Deprecate / remove the IndieAuth token verify endpoint" and moving the spec to be further aligned with OAuth2
  • https://github.com/indieweb/indieauth/issues/33 - align/adopt RFC7662 token introspection
    •   Jamie Tanna has implemented this, and integrated this using the Spring Security and rack-oauth2 OAuth2 clients, and allows for using empty authentication (which could then be HTTP Basic Auth)
    • Recommendation is to not require authentication
      • At some point we should look into this though?
    • Recommendation is to provide this under the token endpoint
      • Does this make sense? Why does RFC7662 expect it to be a separate endpoint?
      • Aaron Parecki: it can be under the same endpoint, but Discovery endpoint could point to the same one
      •   Jamie Tanna should we make it clear in the docs that it could be different
    • should `sub` be a property in the response?

{"active":true,"me":"https://www.staging.jvt.me/","scope":"draft","token_type":"Bearer","client_id":"https://tokens-pls.herokuapp.com","exp":1630780771,"iat":1630175971,"iss":"https://indieauth.jvt.me","aud":["https://www-api.jvt.me/"],"sub":"https://www.staging.jvt.me/"}

      • parked for now, as it's OPTIONAL and unclear if we need it for OAuth2 resource servers to integrate
    • Authentication is likely to be required, but in practice, requires further investigation (see below)
  • Make IndieAuth token verify endpoint credentialed, so it is clear that this should only be used by Resource Servers
    • Aaron Parecki would like this to be some sort of dynamic client registration / "enrollment" that happens automagically when i.e. setting up a relationship with Aperture
    • Discussion as to whether i.e. Aperture / other shared platforms could lead to needing some out-of-band authentication sharing - follow-up investigation required
  •   Jamie Tanna notes that, while integrating his IndieAuth server with OAuth2 clients, he found that the token_endpoint (not the token introspect endpoint, as mentioned on the call) may require `client_id` to be retrieved from `Authorization: Basic ...`, depending on how they work

See Also