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
