On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
George
Very good question...
I considered that the RS metadata discovery could be fake.
Same way that the 'iss' claim must "match" the url used to retrieve the
metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier can't
be spoofed by another site
So the final step in configuration validation is to bind the
relationship between as and rs discovery together to confirm the
relationship is valid.
And what I'd like to see is the 'rsid' value used to represent the RS
rather than some unique endpoint (even if wildcards are allowed)
Another step that may be required is for the RS to return it's 'rsid' in
the realm field of the WWW-Authenticate response header. This allows a
client to discover metadata about the RS and it's endpoints. It also
allows the client to determine if the 'rsid' returned by the RS matches
the 'rsid' it is expecting.
We are of course assuming that a hacker needs to use the real AS
authorize endpoint to succeed in obtaining an access token(it can't be
mitm'd). Once the grant is obtained by the client, the threat comes
when the client uses the grant at a mitm'd token endpoint OR an access
token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding allows
us to extend trust to the RS discovery giving some assurance that a
client has a correct set of endpoints including resource.
Are you recommending that the AS metadata provide a list of the 'rsid'
supported by the AS?
John's solution requires translating aud to res url and changes to
core oauth. He seems to imply there is a need for ongoing validation
of resource. I'm not yet convinced that is really needed. Maybe it is
needed because the client could be convinced to follow a link embedded
in a resource that is somehow not part of the defined audience?
Thanks
Phil
On Mar 16, 2016, at 08:57, George Fletcher <gffle...@aol.com
<mailto:gffle...@aol.com>> wrote:
So, in thinking about all this AS restricting tokens to RS and
"discovery" of RS endpoints, etc. I wondered why we don't just
leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of the
AS. We could do the same with RS metadata retrieving the metadata
from a .well-known location and including a claim of 'rsid' to use as
an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with the
AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource and
the specific endpoints the token will be sent to. A client could
"discover" the necessary endpoint on a periodic basis and use a
single identifier with the AS for any of the endpoints or scopes
supported by the RS. If desired the RS could expose the supported
scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto: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
