It is good to see this RESTful authorization server (AS) discovery mechanism.
It takes me back to 2010 & 2011 when this idea was also discussed.
The "iss" value in the WWW-Authenticate response header should presumably be an
AS's real "iss" value, not an AS's token endpoint address.
So
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example_realm",
iss="https://issuer.example.com/";,
scope="example_scope",
error="invalid_token"
And then the client could get
https://issuer.example.com/.well-known/openid-configuration to find the token
endpoint plus any other parameters it will need.
One concern earlier was that a client app is tricked into sending its client
secret to a bogus AS returned by a malicious resource. This doc mentions
mechanisms such as mutual TLS as a mitigation. But another mitigation should be
that when you have a secret, always know where it can be used.
The WWW-Authenticate header indicating that an OAuth2 delegation dance can be
used to get access is good. Ideally it shouldn't use the Bearer scheme. The
semantics are "one way to continue is to do OAuth 2.0 with this AS", which is
independent of what type of temporary credential that OAuth2 dance delivers.
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
