I'm concerned that forcing the AS to know about all RS's endpoints that
will accept it's tokens creates a very brittle deployment architecture.
What if a RS moves to a new endpoint? All clients would be required to
get new tokens (if I understand correctly). And the RS move would have
to coordinate with the AS to make sure all the timing is perfect in the
switch over of endpoints.
I suspect a common deployment architecture today is that each RS
requires one or more scopes to access it's resources. The client then
asks the user to authorize a token with a requested list of scopes. The
client can then send the token to the appropriate RS endpoint. The RS
will not authorize access unless the token has the required scopes.
If the concern is that the client may accidentally send the token to a
"bad" RS which will then replay the token, then I'd rather use a PoP
mechanism because the point is that you want to ensure the correct
client is presenting the token. Trying to ensure the client doesn't send
the token to the wrong endpoint seems fraught with problems.
Thanks,
George
On 2/24/16 9:59 AM, Phil Hunt wrote:
Nat,
I’m not sure that having the resource server tell the client where its
authorization server is secure by itself. The relationship between the
Authorization Server and the Resource server need to be bound together
in one of the discovery endpoints (the resource and/or the oauth
service discovery).
If a client discovers a fake resource server that is proxying for a
real resource server the current discovery spec will not lead the
client to understand it has the wrong resource server. Rather the fake
resource service will just have a fake discovery service. The hacker
can now intercept resource payload as well as tokens because they were
able to convince the client to use the legit authorization service but
use the token against the hackers proxy.
The OAuth Discovery service needs to confirm to the client that the
server is able to issue tokens for a stated resource endpoint.
This not only works in normal OAuth but should add security even to
UMA situations.
Phil
@independentid
www.independentid.com <http://www.independentid.com>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakim...@gmail.com
<mailto:sakim...@gmail.com>> wrote:
Hi Thomas,
inline:
2016年2月22日(月) 18:44 Thomas Broyer <t.bro...@gmail.com
<mailto:t.bro...@gmail.com>>:
Couldn't the document only describe the metadata?
I quite like the idea of draft-sakimura-oauth-meta if you really
want to do discovery, and leave it open to implementers / to
other specs to define a .well-known URL for "auto-configuration".
The metadata described here would then either be used as-is, at
any URL, returned as draft-sakimura-oauth-meta metadata at the
RS; or as a basis for other metadata specs (like OpenID Connect).
With draft-sakimura-oauth-meta's "duri" and the "scope" attribute
of WWW-Authenticate response header, you have everything you need
to proceed
Yup. That's one of the requirements to be RESTful, is it not?
In OAuth's case, the resource and the authorization server are
usually tightly coupled. (Otherwise, you need another specs like UMA.)
So, the resource server should be able to tell either the location of
the authz endpoint. In some trusted environment, the resource may as
well return the location of the authz server configuration data. In
these cases, you do not have to decide on what .well-known uri as you
say. This frees up developers from configuration file location
collisions etc. We should strive not to pollute the uri space as much
as possible.
(well, except if there are several ASs each with different
scopes; sounds like an edge-case to me though; maybe RFC6750
should instead be updated with such a parameter such that an RS
could return several WWW-Authenticate: Bearer, each with its own
"scope" and "duri" value?)
Yeah, I guess it is an edge case. I would rather like to see these
authz servers to develop a trust framework under which they can agree
on a single set of common scope parameter values.
Cheers,
Nat
On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <jric...@mit.edu
<mailto:jric...@mit.edu>> wrote:
The newly-trimmed OAuth Discovery document is helpful and
moving in the right direction. It does, however, still have
too many vestiges of its OpenID Connect origins. One issue in
particular still really bothers me: the use of
“/.well-known/openid-configuration” in the discovery portion.
Is this an OAuth discovery document, or an OpenID Connect
one? There is absolutely no compelling reason to tie the URL
to the OIDC discovery mechanism.
I propose that we use
“/.well-known/oauth-authorization-server” as the default
discovery location, and state that the document MAY also be
reachable from “/.well-known/openid-configuration” if the
server also provides OpenID Connect on the same domain. Other
applications SHOULD use the same parameter names to describe
OAuth endpoints and functions inside their service-specific
discovery document.
— Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Chief Architect
Identity Services Engineering Work: george.fletc...@teamaol.com
AOL Inc. AIM: gffletch
Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544 Photos: http://georgefletcher.photography
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
