The AS metadata format is a necessary part of discovery. No, it doesn’t
accomplish every possible aspect of discovery – nor was it ever intended to.
I’ve consistently encouraged Phil and others to write down additional aspects
of discovery in specifications that build upon this one so that the working
group and implementers can evaluate them.
Since we’re chartered to do discovery and this is part of discovery, no
rechartering is needed either for the current specification or for new
specifications performing additional discovery tasks.
-- Mike
From: Anthony Nadalin
Sent: Saturday, March 12, 2016 8:20 AM
To: Mike Jones <[email protected]>; Brian Campbell
<[email protected]>; John Bradley <[email protected]>
Cc: oauth <[email protected]>
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
We agreed upon a discovery specification that the WG would work on, we did not
agree upon what this has turned out to actually be, so at the minimum the
chairs should call for adoption of a Authorization Server Metadata
specification and we can continue to work on a Discovery specification
From: Mike Jones
Sent: Saturday, March 12, 2016 8:06 AM
To: Anthony Nadalin <[email protected]<mailto:[email protected]>>;
Brian Campbell <[email protected]<mailto:[email protected]>>;
John Bradley <[email protected]<mailto:[email protected]>>
Cc: oauth <[email protected]<mailto:[email protected]>>
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
The draft enables easy configuration of OAuth clients with an AS. For
instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this
format as an input at client configuration time.
As a side benefit, having this standard AS metadata format and returning the
issuer URL per the Mix-Up Mitigation draft will also enable clients to validate
that they are using a consistent set of AS endpoints and information. But even
without the mitigation benefits, the client configuration benefit is the
primary reason for the specification.
-- Mike
From: OAuth [mailto:[email protected]] On Behalf Of Anthony Nadalin
Sent: Friday, March 11, 2016 3:25 PM
To: Brian Campbell
<[email protected]<mailto:[email protected]>>; John Bradley
<[email protected]<mailto:[email protected]>>
Cc: oauth <[email protected]<mailto:[email protected]>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
Disagree, what purpose is this activity solving then, it was being pushed as
what was need to solve the Mix-up, but that is not true. So now you are
suggesting a change in scope and not dealing with discovery.
From: OAuth [mailto:[email protected]] On Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley <[email protected]<mailto:[email protected]>>
Cc: oauth <[email protected]<mailto:[email protected]>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
I tend to agree with John that addressing the concerns Phil raises should be
part of (extension to) the core protocol. And that those kinds of concerns
don't manifest in the way OAuth is typically deployed now.
The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should
keep it's scope to the publishing of authorization server metadata. The act of
doing discovery is beyond its scope and so is trying to prevent a client from
presenting a token to someplace it shouldn't.
On Fri, Mar 11, 2016 at 9:08 AM, John Bradley
<[email protected]<mailto:[email protected]>> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM)
<[email protected]<mailto:[email protected]>> wrote:
John
In many case all the AS has to check is the domain name component to check for
mitm.
POP and the other solns are dramatically more complex than a simple check.
I was proposing ding that check at the authorization endpoint or token endpoint
as part of AT issuance.
It is up to the AS how much of the path to validate and or put in the aud or
dst.
I see it as part of the discovery(bad name aside) problem because we discussed
that if a client finds
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com%2f&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fiS8f60ypiXhyM0qVTeql%2b%2bOzH2wbmECQE7J5TtGPQM%3d>
how do we ensure it gets a complete set of oauth endpoints as a valid set of
endpoints--that a hacker has not inserted one of their own endpoints. The most
important endpoint to get right is ensuring the resource server (and optionally
the path) is the correct one. We can't really define resource discovery but we
can validate it to some degree.
I think it is part of core protocol security and should/must not require
discovery.
What is
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jAsZQeChJ%2bR1lbyBoVKwheIYi3PiWLrq%2bxDLbqU6rxk%3d>
?
If it is the resource then the client would be preconfigured for it’s AS out of
band or optionally would do discovery on the issuer uri that you admit needs to
be configured out of band some way (note discovery is optional)
In the AS meta-data draft it would do a get on a well known file that would
have configuration for the AS, but not the RS, though some API may optionally
list a API endpoint like connect has.
The client then makes a authorization request (after registering out of band or
dynamically).
As part of the authorization request for implicit it could provide the aud/dst
that it wants the token for.
If that is not sent then the aud/dst are implicit in the scopes.
The client gets back a AT with a list of scopes granted, aud/dst allowed and
time to live for the token (one extra thing returned)
This doesn’t require any discovery (yes there is a optional AS meta-data
discovery but not required)
I prefer to fix the RS man in the middle issue as part of the protocol and not
part of discovery that should remain optional.
I honestly don’t quite know how the client learns about this bad RS and starts
talking to it, so this may be a solution to a problem that doesn’t yet exist.
The one place this is posable is if the registration for the client is
compromised. However we are discussing other mitigations for that that also
explicitly do not require discovery.
John B.
I am not stuck on webfinger or well-known. Because this is config maybe it
should be an oauth endpoint.
Phil
On Mar 11, 2016, at 06:51, John Bradley
<[email protected]<mailto:[email protected]>> wrote:
I think Phil is proposing something different. Should the client send a token
from this AS to that RS.
His goal is to prevent man in the middle attacks where a bad RS gets a AT that
is audianced to/accepted by another RS.
That is separate from the question of if a RS accepts tokens from a good AS.
A bad AS would always say yes.
We need to be careful of what if anything the RS provides to the client as
meta-data without validation.
Currently the client can provide a list of scopes required to get access. I
personally feel it would be useful to also include in the unauthenticated error
response an indication of what API the resource supports. Say “scim2” as an
example. I don’t think adding that is however a high priority as most if all
clients know what API they expect. It might be useful if at some point in the
future if a client were to be given a RS URI it could check to see if it is a
protocol that it supports before bothering with OAuth. I expect that a lot
of people will want that left to the API definition. I think we can talk
about it but rate this low priority.
I agree that the RS giving out a list of AS that it trusts is a generally bad
idea. I hope that is not on the table.
I don’t think that preventing a client from sending a token to the wrong RS is
part of a AS meta-data discovery problem.
I do however think that it is important.
We have been discussing this as a separate problem to AS meta-data discovery
where the endpoints of the AS and it’s configuration are discovery. Sorry for
perhaps stating the obvious, but the RS is explicitly not part of the AS in
OAuth 2. Starting in WAP that was a core principal.
So we have a number of options to address the RS token leakage via MiTM attacks.
1) PoP bound tokens. If they are bound to the TLS channel by mutual TLS or
Token binding they cannot be replayed. Signed messages where the signing
covers the RS Host and path components, also would work.
2) Have the AS audience restrict the resources the AT is good at. (AT should be
doing that now)
In the token response include the list of audience/s the token is presentable
at. The client would throw an error if the RS it intends to send the token to
is not on the list. The RS the token is good at might change based on scopes,
client_id and resource owner. This is the place where all of that comes
together. In some cases the RS and AS might not have a pre-established
relationship. The client should send the RS base URI to the AS as part of the
request. The AS can use that to audience restrict the AT and issue the AT or
refuse to issue the AT based on policy.
It can also use the audience in the request to down audience the AT if the
default is to have multiple audiences. We may want to use a term other than
audience for this like resource or destination. It is a audience but that term
might confuse people with AT.
We did talk about breaking audience out of POP key distribution, and Brian
Campbell did a draft
https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-campbell-oauth-dst4jwt&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=STr%2b4krd1hy8h6eHOCLh1PzQaKMUhWlKV2i%2fCL0K1SQ%3d>.
To do this we could take dst4jwt and add another spec that adds a new dst
parameter to the token and authorization endpoints requests That would be a
space separated list of dst values. and in the response from the token
endpoint would be a JSON array of dst values.
3) Have the AS always return all the list of all RS the token can be used at
(basically Nat's link relationship proposal). It needs a way to handle
down destinationing of AT and to allow for un-configured RS that it might issue
a token for. So could be combined with dst from 2. Basically returning the
acceptable destinations as link headers vs JS in the response is mostly a style
issue that other people can bike shed.
4) Trying to add all the RS to the AS discovery document. This seems
impractical as there would be multiple protocols and doesn’t address
un-configured RS.
5) Some new AS endpoint that the client could introspect the RS URI and get
back metadata about if the client should send tokens there.
A couple of problems with this. The first is that it would not support
un-configured RS unless you add dst to the token and authorization endpoints.
The other is that the introspection endpoint doesn’t have the context of the RO
and client_id unless you also pass the code/RT and client_id, and probably
client credentials. Basically this is trying to introspect the AT to
determine the audiance/dst. By the time you build a new introspection
endpoint securely it is going to look like the token endpoint with a bit more
meta data about the token beyond expiry and scopes.
I think we should go a head with the renamed "OAuth 2.0 Authorization Server
Discovery Metadata”
I am also fine with making the default document 'openid-configuration’ as long
as we allow for protocol specific variation so that SCIM2 could define a file
name. If people want we could do a API to file name registry so that
protocol specific ones can be defined.
We are all-ready working on option 1 to secure AT, we need a spec like I
propose in 2 for bearer tokens. We can add one request parameter and a bit
more token meta-data to the token response and that takes care of the problem.
Honestly we probably should have separated scope and destination in the first
place and returned both dst and scope in the response all along, so this is
update that is consistent with the eisting architecture of OAuth 2.
Lets keep the two issues separate.
John B.
On Mar 11, 2016, at 12:07 AM, Anthony Nadalin
<[email protected]<mailto:[email protected]>> wrote:
The relationship between AS and RS need to be scoped to “does this RS accept
tokens from this AS” as a list is too much information that could be used in
the wrong way
From: OAuth [mailto:[email protected]] On Behalf Of Nat Sakimura
Sent: Thursday, March 10, 2016 6:25 PM
To: Phil Hunt (IDM) <[email protected]<mailto:[email protected]>>
Cc: oauth <[email protected]<mailto:[email protected]>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
Phil,
Right. So what my conditional approvals (11 conditions in total) said was to
drop the word "discovery" from everywhere. This is not a discovery spec. This
is a configuration lookup spec as you correctly points out. So, I am with you
here.
Also, my 2nd conditiion is essentially saying to drop section 3.
One thing that I overlooked and am with you is that we need to be able to
express the AS-RS relationships. I have been preaching this in the other thread
for so many times as you know so I thought I pointed it out, but missed
apparently in my previous comment. So, I would add my 12th condition:
12. A way to express a list of valid RSs for this AS needs to be added to
section 2.
Best,
Nat
2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM)
<[email protected]<mailto:[email protected]>>:
I strongly oppose. 2 major issues.
This is not service discovery this is configuration lookup. The client must
have already discovered the oauth issuer uri and the resource uri.
The objective was to provide a method to ensure the client has a valid set of
endpoints to prevent mitm of endpoints like the token endpoint to the resource
server.
The draft does not address the issue of a client being given a bad endpoint for
an rs. What we end up with is a promiscuous authz service giving out tokens to
an unwitting client.
Phil
On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov
<[email protected]<mailto:[email protected]>> wrote:
+1 to move forward with these
On 10/03/16 17:35, Brian Campbell wrote:
+1
On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg
<[email protected]><mailto:[email protected]>
wrote:
I support this document being moved forward with these two changes:
- change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
proposed by Brian and
- use the URI path suffix ’oauth-authorization-server’ instead of
’openid-configuration’ as proposed by Justin.
18 feb 2016 kl. 14:40 skrev Hannes Tschofenig
<[email protected]<mailto:[email protected]>
:
Hi all,
This is a Last Call for comments on the OAuth 2.0 Discovery
specification:
https://tools.ietf.org/html/draft-ietf-oauth-discovery-01<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-discovery-01&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=w3%2biiaWon81LJCU%2b2mCPRmA%2brECBHgqyRr0OgqiWSHU%3d>
Since this document was only adopted recently we are running this last
call for **3 weeks**.
Please have your comments in no later than March 10th.
Ciao
Hannes & Derek
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
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%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>
— Roland
”Everybody should be quiet near a little stream and listen."
>From ’Open House for Butterflies’ by Ruth Krauss
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
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%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
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%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
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%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6FVmdN7ad0YzoYKSNF%2fDO%2ffG2EF1haj5aOHiMid6UMI%3d>
@_nat_en
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
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%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bKsEVBUXc528yaAMLmycXcL33%2bFJCQrnq9asxRo5He8%3d>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
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%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bKsEVBUXc528yaAMLmycXcL33%2bFJCQrnq9asxRo5He8%3d>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
