OAuth2 discovery versus OIDC discovery

[bbockelm]

The location of the .well-known directory is a bit of a mess.

• The location of the directory is defined by RFC 5785.
• OIDC's definition of .well-known violates RFC 5785 but is codified in the OIDC standard and in wide use in software implementations.
• There's a draft standard for OAuth Discovery which is strongly motivated by OIDC but complies with RFC 5785.
• The draft OAuth Discovery allows clients in mixed use environments to use either approach.

So - what should we do?

[jbasney]

SciTokens should use OAuth Discovery, since SciTokens is OAuth, not OIDC.

Similar issue in scitokens-java.

[bbockelm]

But even there, we have:

And it should be published at issuer/.well-known/oauth-authorization-server rather than issuer/.well-known/openid-configuration.

Whereas the OAuth discovery (and RFC 5785) says this should be:

.well-known/oauth-authorization-server/issuer

[jbasney]

Brian, I guess you're referring to https://tools.ietf.org/html/draft-ietf-oauth-discovery-10#section-3.1 and https://tools.ietf.org/html/draft-ietf-oauth-discovery-10#section-5 which discusses how to form the discovery URI when the issuer contains a path component? I don't see anything about .well-known/oauth-authorization-server/issuer in https://tools.ietf.org/html/rfc5785.

It seems clear to me.

issuer = https://scitokens.org/
discovery = https://scitokens.org/.well-known/oauth-authorization-server

issuer = https://scitokens.org/ligo
discovery = https://scitokens.org/.well-known/oauth-authorization-server/ligo

Personally I find https://tools.ietf.org/html/draft-ietf-oauth-discovery-10#section-5 a bit of a mess, so I'd strongly recommend against issuers containing path components to avoid that particular mess. I think there's a decent chance that will change before the RFC is published.

[jbasney]

Following the example at https://tools.ietf.org/html/rfc5785#section-3:

For example, if an application registers the name 'example', the
corresponding well-known URI on 'http://www.example.com/' would be
'http://www.example.com/.well-known/example'.

In our case, the application name is "oauth-authorization-server" so if our issuer is "https://scitokens.org/" then we get "https://scitokens.org/.well-known/oauth-authorization-server".

[bbockelm]

You're right - RFC 5785 doesn't really touch this, other than being fairly clear that .well-known belongs to the top-level (which, of course, OIDC doesn't do...).

What's your feeling of the status of the OAuth Discovery document? The WLCG folks were reluctant to follow it as it's still a draft. Given the implementations being considered on the WLCG side are also OIDC clients, there was a strong preference to utilize OIDC mechanisms.

[jbasney]

https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ shows it is far along in the process. The change to the URI form for issuers containing path components happened recently during IESG review for BCP 190 conformance. It's farther along than https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ which we're already depending on.

Given the feedback from WLCG, I'm guessing SciTokens needs to support both OIDC and OAuth discovery, with OAuth discovery as our recommended/preferred approach, since I think we want to avoid any explicit dependencies on OIDC (according to our "SciTokens is OAuth, not OIDC" principle).

[bbockelm]

I think that as long as our libraries try the OAuth2 mechanism and fall back to OIDC, we should be fine. If I parsed yesterday's conversation correctly (they haven't updated the working docs to reflect the discussion), WLCG will do the same once the OAuth2 discovery mechanism is an official RFC.

[jbasney]

OAuth Discovery is now RFC 8414, so we don't need to worry about "just a draft" concerns anymore.