Consider using OAuth Server Metadata

[aaronpk]

Currently IndieAuth clients discover two pieces of information from the user's profile page, the authorization endpoint and token endpoint. As we continue to expand IndieAuth into new use cases (such as automated indieauth between two machines acting on behalf of users), we may need to include additional information to clients.

If IndieAuth 1.1 is not backwards compatible with IndieAuth, (such as if PAR is a requirement), clients will need to know which version is supported in order to know how to behave, and that means either adding another link tag or changing the names of the rel values.

There is an OAuth extension which talks about how to communicate information about an OAuth server to clients by publishing a JSON document at the metadata URL for the server.

We could instead have the IndieAuth client look for just one value in the HTML, the metadata endpoint, and have the client fetch everything else from there. While this does add an HTTP request in the initial setup compared to the current state, it may end up being preferable longer term. (PAR ends up adding a request in the setup too anyway.)

A straw proposal for how this could work is:

• Client fetches the user's entered profile URL and looks for <link rel="indieauth_metadata" href="https://indieauth.example.com/metadata.json"> (the filename does not need to be standardized since it's discoverable from this link)
• Client parses that document looking for the properties authorization_endpoint and token_endpoint
• Client sends a pushed authorization request to the authorization endpoint, then redirects the browser to the resulting URL
• ... continue as normal

[pfefferle]

If the new version of IndieAuth is not backwards compatible, I would vote for a major change of the version number and call it 2.0 (https://semver.org/).

[jamietanna]

Is this expected to be similar to OpenID Connect Discovery?

What sort of properties are we thinking would be provided?

I would guess:

• authorization_endpoint
• grant_types_supported
• response_types_supported
• scopes_supported
• token_endpoint

But is there anything specific we'd want for IndieAuth? Maybe something like whether we support #40?

[manton]

I don't know enough yet to comment on whether this is needed, but if it is, what about simply rel="indieauth", without the "_metadata"? That seems more consistent with "micropub", "microsub", and "webmention".

[aaronpk]

Technically once you add all the OAuth 2.0 extensions on top, OAuth 2.0 isn't even backwards compatible with itself. But in any case, the name isn't super relevant to this discussion.

The extension point from OAuth is RFC8414. The two main ones needed are authorization_endpoint and token_endpoint, I could see scopes_supported potentially being useful too. In general I'd want to leave out as much as possible unless there's a clear reason to add it.

rel="indieauth" could work, I guess I suggested indieauth_metadata first because this URL isn't the indieauth server itself, it's a document describing the server. But in any case it's more important to decide whether this is even a good idea than what it's called right now.

[aaronpk]

Removing this from the GitHub milestone for now while we focus on the current open issues we discussed at the popup.

[aaronpk]

We should revisit this once we have a backwards-incompatible change we want to make to IndieAuth such as #40

[jamietanna]

My IndieAuth server now supports this at https://indieauth.jvt.me/.well-known/oauth-authorization-server:

{
  "authorization_endpoint": "https://indieauth.jvt.me/authorize",
  "code_challenge_methods_supported": [
    "S256"
  ],
  "grant_types_supported": [
    "refresh_token",
    "authorization_code"
  ],
  "introspection_endpoint": "https://indieauth.jvt.me/token_info",
  "issuer": "https://indieauth.jvt.me",
  "response_modes_supported": [
    "query"
  ],
  "response_types_supported": [
    "code"
  ],
  "scopes_supported": [
    "read",
    "profile",
    "update",
    "mute",
    "media",
    "follow",
    "delete",
    "notify",
    "channels",
    "draft",
    "undelete",
    "create",
    "block"
  ],
  "token_endpoint": "https://indieauth.jvt.me/token"
}

My profile URL shares:

rel=indieauth  "https://indieauth.jvt.me"
rel=indieauth-metadata "https://indieauth.jvt.me/.well-known/oauth-authorization-server"

[aaronpk]

Note that in #17 we shouldn't use underscores in HTTP headers.

rel=indieauth-metadata

[capjamesg]

@jamietanna Can you clarify what "response_modes_supported" means in your example? I am thinking of implementing this but was not sure what other values someone could state.

[jamietanna]

@capjamesg sorry for the late reply, the response_modes_supported means where the Authoritzation Server will put the code parameter into the redirect as part of the Authorization Code Grant.

For IndieAuth, it's always query as it's in the querystring.

Just thought I'd add the metadata for it

[capjamesg]

Thank you for the clarification @jamietanna.

[jamietanna]

Closing, as this is now adopted by #102.