Yeah, unfortunately the WWW-Authenticate solution advertising an AS has bad
(fatal) security problems. That's the underlying reason/urgency behind a
separate services discovery mechanism. It's not that we ignored
WWW-Authenticate, and in fact I'm in process of ripping that mechanism out of a
draft I'm working on.
This is not hard when the protected resource or user identifier is in a domain
where WebFinger (WF) will work. The problem comes when we have, for example, N
email domain names all served by the same AS, and you have to discover that
way. The solution there may be that you take an indirect path through the MX
record (one suggestion), determine the domain from that, and do the WF lookup
based on the MX domain.
For arbitrary webservices running on a domain where they can't run their own WF
endpoint we don't yet have a solution. At some point the client may well be
expected to know somehting about the identity it expects to use for a site.
-bill
>________________________________
> From: "Manger, James H" <james.h.man...@team.telstra.com>
>To: Sergey Shishkin <sergei.shish...@gmail.com>; "oauth@ietf.org"
><oauth@ietf.org>
>Sent: Tuesday, May 15, 2012 10:30 PM
>Subject: Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
>
>
>Sergey,
>
>A hypermedia-driven (RESTful) API should be able to use OAuth. Unfortunately,
>OAuth does not have a RESTful design.
>
>Most APIs require client apps (not just the user) to be pre-registered with
>the service. That seems to have made hypermedia-driven design less important —
>if a client app has to explicitly register with a service it may as well learn
>details like the authorization URI at registration time as well.
>
>A WWW-Authenticate response header that identifies an authorization server
>(AS) would be a great hypermedia-driven solution. It tells the client app
>which AS a service trusts. The client app can then get a token. Before sending
>a AS-issued token to the original service the client app needs to know the AS
>trusts that service. Unfortunately this detail is missing from OAuth: tokens
>are issued with no indication of where they can safely be used
>[http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-4.1.4].
>
>--
>James Manger
>
>From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John
>Bradley
>Sent: Wednesday, 16 May 2012 3:45 AM
>To: Sergey Shishkin
>Cc: oauth@ietf.org
>Subject: Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
>
>The danger is a bad resource, If that can redirect the client to a arbitrary
>AS to phish the resource owner's credentials that is a bad thing.
>
>The presumption is that the client knows where the trusted AS for that
>resource is, and if it needs to discover it that is a much bigger issue.
>
>In the IMAP case the client probably needs to do discovery on the identifier
>itself to figure out where to send the user.
>
>John B.
>On 2012-05-15, at 1:18 PM, Sergey Shishkin wrote:
>
>
>
>Bill,
>
>it might be me misreading the Implicit Grant Flow, but I understood it like
>this:
>
>1. client tries to get a resource from server;
>2. server redirects client to auth-service;
>3. client authenticates against auth-service (HTTP Basic or whatever);
>4. auth-service redirects client back to the resource;
>5. client tries to get the resource providing the token.
>
>In step 3 the client is of course responsible for protecting its password from
>phishing, so auth-service should authenticate itself with a certificate.
>
>Am I right? If, yes my idea was to use this flow while choosing a standardized
>token - Bearer. But Bearer insists on 401 instead of redirects and that
>confused me.
>
>Sergey
>
>On Tue, May 15, 2012 at 6:24 PM, William Mills <wmi...@yahoo-inc.com> wrote:
>You can hard configure it into your client, that's safe. The problem comes
>when the client can be sent to an arbitrary, possibly phishing, site to do
>authentication. If the client supports the password grant then it probably
>just hands in the username and password without user interaction.
>
>-bill
>
>>
>>________________________________
>>
>>From:Sergey Shishkin <sergei.shish...@gmail.com>
>>To:William Mills <wmi...@yahoo-inc.com>
>>Cc: "oauth@ietf.org" <oauth@ietf.org>
>>Sent: Tuesday, May 15, 2012 9:09 AM
>>Subject: Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
>>
>>In my scenario I control both the resource provider and the token issuer and
>>I'm fine with the resource provider knowing the issuer. So, discovery is not
>>needed. Or do I miss something?
>>On Tue, May 15, 2012 at 6:04 PM, William Mills <wmi...@yahoo-inc.com> wrote:
>>Yes, what you're running across here is the "discovery" problem. How do you
>>discover the authentication endpoints for a service. Unfortunately it turns
>>out returning that as part of the 401 has big security concerns. It's still
>>being figured out.
>>
>>>
>>>________________________________
>>>
>>>From:Sergey Shishkin <sergei.shish...@gmail.com>
>>>To: oauth@ietf.org
>>>Sent: Tuesday, May 15, 2012 5:12 AM
>>>Subject: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
>>>
>>>While designing a hypermedia-driven API I'm evaluating possibilities to use
>>>OAuth Bearer tokens for claims-based authorization. Currently I struggle
>>>with how to communicate to the API client the way to obtain the token. In a
>>>hypermedia-driven manner I don't want the API client to get this information
>>>out of band, but rather let the client "just follow the links".
>>>
>>>The Bearer draft
>>>[http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19#section-3] advises
>>>to send a 401 response with a WWW-Authenticate challenge specifying optional
>>>realm and scope. The problem here: neither realm nor scope identify the
>>>token issuer.
>>>
>>>The OAuth 2.0 draft
>>>[http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-4.1.1] suggests
>>>to redirect the resource owner to the token issuer, IIRC. I like this way
>>>from the hypermedia perspective, but still have mixed feelings about missed
>>>401 and WWW-Authenticate challenge.
>>>
>>>Did I missed some part of draft covering my scenario? Are there any known
>>>grassroots implementations doing just that on the internet? Any opinion on
>>>the subject is very much appreciated.
>>>
>>>Thanks in advance,
>>>Sergey
>>>
>>>_______________________________________________
>>>OAuth mailing list
>>>OAuth@ietf.org
>>>https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>>
>
>_______________________________________________
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>
>_______________________________________________
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
