2021/Pop-ups/IndieAuth2

From IndieWeb
Jump to: navigation, search


IndieAuth 2 2021 was an IndieWebCamp Pop-ups 2021 session and the 2nd IndieAuth session of 2021.

Summary

At the end of the last IndieAuth protocol session, there was a discussion of following up in a few weeks to finish what we could not. This popup IndieWebCamp session will continue the discussion to iterate and evolve the IndieAuth protocol.

Details

Topics

  • Make IndieAuth token introspection endpoint credentialed, so it is clear that this should only be used by Resource Servers. While there was a consensus on adopting the token introspection endpoint request and response, we did not conclude on what type of authentication. https://github.com/indieweb/indieauth/issues/99
    • Authentication is likely to be required, but in practice, requires further investigation (see below)
    • 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
    • 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)
    • Consensus for now: Add to PR on introspection it is required, but not specify how at this time, allowing implementers to decide.
  • Introduce OAuth Server Metadata https://github.com/indieweb/indieauth/issues/43
    • Jamie Tanna has a metadata endpoint now, getting it working was pretty straightforward
    • David Somers has a metadata discovery facility: see https://toolbox.imoxia.com/#authmetadisco (now supports discovery using rel=indieauth_metadata)
    • Rel=indieauth-metadata as opposed to rel=indieauth to indicate it is the metadata endpoint over being confused for the issuer URL. Opportunity to use - over _ as _ not allowed in http headers.
    • May address #98 in that we could more easily add endpoints.
    • Recommend placing it as .well-known for compat, but not require?
    • Note about fallback to old endpoints for compat
  • Consider adopting the iss parameter https://github.com/indieweb/indieauth/issues/101
    • Dependent on the iss parameter being defined in the server metadata document. So, no fallback if there is a metadata document.
    • iss value should be the home page of the indieauth server, and is expliclty not the authorization endpoint
  • Discuss whether IndieAuth adopt resource indicators(https://github.com/indieweb/indieauth/issues/82) as a notation, and note any specific considerations for IndieAuth. Even though Ticket Auth prompted this, this is not specifically a Ticket Auth issue. Proposed PR https://github.com/indieweb/indieauth/pull/96
    •   Jamie Tanna adds the `aud` of `https://www-api.jvt.me/` into all tokens, and currently does not enforce it anywhere. The enforcement would be added in the future, restricting at a resource server level whether the access token can be utilised
    • Discussion is also around whether we use Resource Indicators for Ticket Auth
    • Sample private post doing www-authenticate: https://toolbox.imoxia.com/private/codecow with a realm indicator
    • Scopes may not be required if resources are provided, and this could be specified in spec.
    • Whether an access token is issued changes from only whether scopes are requested to whether scopes or resources are requested
  • Making the various token endpoint overrides consistent https://github.com/indieweb/indieauth/issues/98
    • Rewrite Introspection PR to support metadata to no longer be part of token endpoint as proposal.
    • Consider rewriting revokation to be defined as an endpoint with server metadata.
  • Clarifying what names are returned in user profiles https://github.com/indieweb/indieauth/issues/93
    • Define name in the spec and its application.
    • It feels like the most straightforward solution would be to keep the existing "name" param and define it more specifically in the spec
  • Clarify whether profile information is returned when a refresh token is used
  • Consider adopting a userinfo endpoint, possibly after OAuth server metadata



Not Discussed