Closed jjg-123 closed 2 months ago
I'm a little confused: the well-known configuration URL is based on the issuer, so why would you get the issuer from the former? I probably miss the use-case See also OIDC-Discovery spec and later OAuth2 AS Metadata RFC8414 Sec. 3 and idem Sec. 5
Good question. Because this is about convenience configuring the command line client. We want to make the configuration as minimal as possible, here if the user specifies only the well-known endpoint in the configuration, then the client can introspect for all the values, including the issuer. Note also that OA4Mp supports multiple issuers on a single server, so this is actually a good idea in some cases. Cf. If the user specifies only the endpoint for the service, then the well-known page is gotten as per the spec.
Ok, I think I get the use-case, although I'd say configuring the whole .well-known endpoint is actually less minimal than just the issuer (where the software then constructs the former via https://datatracker.ietf.org/doc/html/rfc8414#section-3 or https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig).
Also note that the extra /oauth2/
is not in line with those specs since the issuer doesn't contain it. But I did notice that
See https://github.com/ncsa/oa4mp/issues/175 The issue for Tomcat is that a well-known page has to be for the system, so can't be directly a part of an OA4MP distro per se. OA4MP may also be part of another system (like CILogon) which handles the redirects to the oauth2/.well-known endpoint itself. As such, how to do it needs to be documented.
Since the command line client is now getting all of its other information from the well-known page, we should get the issuer as well.