Hi Filip, Thanks for your answers!
I'm not quite sure if the wording in my question was clear: My main concern is the difference between https://example.com/some/path*/.well-known/oauth-authorization-server* and https://example.com*/.well-known/oauth-authorization-server*/some/path, i.e., the usage of the well-known URI as a postfix or as an infix. Am 08.06.20 um 09:54 schrieb Filip Skokan: > Some products publish both, but they don’t always return the same > content, eventho as far as i can tell they should be aliases. > The uri normalization of 8414 is also implemented wrong in some cases, > since it differs from OIDC as far as issuer path component is concerned. This is where I'm not sure whether all products follow RFC8414 and properly use the well-known part as an infix. > > I find it best for AS to have just one or both with the same content, > client software doing discovery can check both locations. That would be the safe implementation, but I was wondering if prescribing this is a good choice for an ecosystem. That would mean that all authorization servers in the ecosystem would need to implement both https://example.com/some/path/.well-known/oauth-authorization-server and https://example.com/.well-known/oauth-authorization-server/some/path. Even if it is only an alias this could mean a considerable overhead for some implementations. -Daniel > > Odesláno z iPhonu > >> 8. 6. 2020 v 9:46, Daniel Fett <f...@danielfett.de>: >> >> >> >> Hi all, >> >> RFC8414 says that the URI where the OAuth metadata document is >> published is >> >> formed by inserting a well-known URI string into the authorization >> server's issuer identifier between the host component and the path >> component, if any. By default, the well-known URI string used is >> "/.well-known/oauth-authorization-server". >> >> I found that some OAuth servers and clients instead follow the >> convention used by OpenID Connect, where the suffix >> "/.well-known/openid-configuration" (or >> "/.well-known/oauth-authorization-server") is appended to the issuer URL. >> >> Is this a common deviation from the spec? >> >> Do you know how specific products handle this? >> >> Does it make sense to serve the metadata document from both locations? >> >> -Daniel >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth -- https://danielfett.de
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
