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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
