We could add a statement something like this to the security considerations:
“Publishing information about the authorization server in a standard format
makes it easier for both legitimate clients and attackers to use the
authorization server.”
I believe that speaks to the point you’re making.
-- Mike
From: Anthony Nadalin
Sent: Wednesday, February 24, 2016 10:26 AM
To: Mike Jones <michael.jo...@microsoft.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
Sure there is, it is as you have now made it far easier and the security
considerations does not even address this
From: Mike Jones
Sent: Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin <tony...@microsoft.com<mailto:tony...@microsoft.com>>
Cc: <oauth@ietf.org<mailto:oauth@ietf.org>>
<oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
As we’d discussed in person, there’s no effective security difference between
discovery information being published in an ad-hoc fashion on developer pages
and it being published in a standard format. “Security by obscurity” adds no
real security at all.
-- Mike
From: Anthony Nadalin
Sent: Wednesday, February 24, 2016 10:01 AM
To: Mike Jones
<michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>; Phil Hunt
(IDM) <phil.h...@oracle.com<mailto:phil.h...@oracle.com>>; Nat Sakimura
<sakim...@gmail.com<mailto:sakim...@gmail.com>>
Cc: <oauth@ietf.org<mailto:oauth@ietf.org>>
<oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> The point of the WGLC is to finish standardizing the core discovery
> functionality that’s already widely deployed.
That may be widely deployed for OIDC but not widely deployed for OAuth. There
are some authentication mechanism discovery for endpoint that really should not
be in an OAuth standard since it’s really not dealt with. Now that all this
information is available it makes poking around the endpoint more focused for
people that want to disrupt your endpoints, that is really not addressed in the
security considerations section at all
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) <phil.h...@oracle.com<mailto:phil.h...@oracle.com>>; Nat
Sakimura <sakim...@gmail.com<mailto:sakim...@gmail.com>>
Cc: <oauth@ietf.org<mailto:oauth@ietf.org>>
<oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
The point of the WGLC is to finish standardizing the core discovery
functionality that’s already widely deployed.
None of Nat or John or I are suggesting that additional related functionality
won’t be created. I’m sure it will be. Some applications will use WebFinger
to locate the discovery metadata. Some will possibly use link headers. Some
will possibly use application-specific .well-known values. I’m sure there’s
other things I haven’t even thought about. All of these depend upon having a
discovery metadata document format and none of them change it – other than
possibly to register additional discovery metadata values.
So by all means, the working group should continue discussing inventing
possible new related mechanisms that make sense in some contexts. At the same
time, we can finish standardizing the already widely deployed core
functionality that all of these mechanisms will need.
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura <sakim...@gmail.com<mailto:sakim...@gmail.com>>
Cc: <oauth@ietf.org<mailto:oauth@ietf.org>>
<oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
I am suggesting that part of the discovery solution has to be the client
indicating what resource endpoint it wants the oauth configuration data for.
So if
res.example.evil.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fres.example.evil.com&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Pc%2b7ilnDYgfjYoTsQWoZnpobG%2bVJp5Wu9cGpFUgz3S0%3d>
is not a valid resource endpoint for
as.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fas.example.com&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6%2bqxh%2f7VCZkswXhJMv6r%2b18dTRbg2Is12WB%2fdZm3cJ4%3d>
the authz discovery should fail in some way (eg return nothing).
There may be better ways to do this. Eg combine discovery. Or change the order
of discovery.
One of OAuth's strength's and weaknesses is that the target of authorization
(the resource) is never specified. It is often bound up in the client
registration and an often implied 1:1 relationship between resource and as.
Given that in discovery phase registration has not yet occurred it seems
important that the client know it has a valid combination of endpoints etc.
This is why I was disappointed about wglc on discovery. We had a starting point
for group adoption but we haven't really defined the full requirements IMO.
I am on vacation or I would put some thought into some draft changes or a new
draft. I apologize I can't do it now.
Phil
On Feb 24, 2016, at 08:12, Nat Sakimura
<sakim...@gmail.com<mailto:sakim...@gmail.com>> wrote:
Hi Phil,
Are you suggesting that the AS metadata should include the RS URIs? Currently,
it does not, but it can be done, I guess.
The way oauth-meta works is that
1. RS tells the client where the AS is.
2. AS tells the client which RS endpoints the token can be used.
Even if there is a bad AS with a valid certs that proxies to the good RS, the
client will not send the token there as the authz server will say that is not
the place the client may want to send the token to.
Nat
2016年2月24日(水) 23:59 Phil Hunt
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>>:
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<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.independentid.com&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MJWpFB12vTLB4ecKyYwlZLnRJInaNEw1MwlvtU26BPA%3d>
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<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=go1FhL%2bDa6yBSKmcs3wql71BskY7N7EJx40pZPJxtl4%3d>
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=go1FhL%2bDa6yBSKmcs3wql71BskY7N7EJx40pZPJxtl4%3d>
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=go1FhL%2bDa6yBSKmcs3wql71BskY7N7EJx40pZPJxtl4%3d>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
