On Mar 16, 2016, at 11:29 AM, George Fletcher
<<mailto:gffle...@aol.com>gffle...@aol.com> wrote:
Inline...
On 3/16/16 2:16 PM, Phil Hunt wrote:
Phil
@independentid
<http://www.independentid.com/>www.independentid.com
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On Mar 16, 2016, at 10:59 AM, George Fletcher
<<mailto:gffle...@aol.com>gffle...@aol.com> wrote:
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 attacker makes iss and url match for the resource
discovery. Yet the AS service provider doesn’t know where the
client is using the tokens. How would the client or the AS detect
that the wrong iss was given?
Because if the attacker makes the rsid and the url match, then the
client will submit an rsid that isn't "registered" with the AS and
the AS won't issue the token. This assumes the client is not
talking to an evil AS (as there are other mitigations for that case).
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)
Long term, I think this would be better. Do we have a way to issue
RSID values in the works?
No, but that is what this email thread is contemplating:) Just as
the AS iss value is selfdefined by the AS, the rsid should be
selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
is a mirror of how the AS 'iss' claim is defined for the AS in it's
metadata.
That said, I would have thought this is more ownerous than
checking *.example.com <http://example.com/>matches the given URL
by the client.
My problem with the URL level checking is that a RS may
legitimately have endpoints on multiple domains. An RS may move
endpoints from one domain to another (say when moving from version
1 to version 2 of an API). Using the rsid for audience restriction
and as an indirect mechanism for specifying actual endpoints, the
RS has a much looser coupling with the AS.
AS we move into "federated authorization" meaning that an RS
outsources it's API authorization to one or more AS's, this will
become more important.
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.
Agreed. This might work. But should the check be when the client
asks for the configuration metadata or when the client asks for
tokens? I think it only needs to happen at config time.
What I see here is that the desire is to audience protect tokens.
To do that, the audience need to be specified everytime a token is
requested. I really don't the AS to have to manage the complex
state of which audiences have previously been issued to
refresh_tokens and then reconstruct the correct audience for a
requested downscoped access_token. It's much simpler, since the
client knows which RS it's going to send the token to, to provide
that when requesting tokens.
The complication comes when exchanging the code for the tokens, it
needs to specify all possible audiences (rsid's) it might send the
token to based on the requested scopes. There will be a fair amount
of complex logic at the AS to ensure the correct behavior. I do
worry about this complexity.
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?
No. I think that is a bad idea. Better to use an identity oracle
function and say, give me the config for rsid=xyz
Good :)
That also allows a common AS discovery endpoint to actually do
discovery for multiple AS systems. E.g. to configure a client to
a specific AS service designated by the customer paying for the
resource service.
IOW. by providing a resource query, the meta-data config discovery
actually looks more like discovery. :-)
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> 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
<mailto:OAuth@ietf.org>OAuth@ietf.org
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth
