Justin, I want to let client (API client, not OAuth Client) know less to get the job done. The service should ideally be able to encode everything required in a URL and give it to the client. This is what is described in the Implicit Grant Flow [ http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-4.2], right? So, why does Bearer spec insist on 401?
Sergey On Tue, May 15, 2012 at 3:45 PM, Justin Richer <jric...@mitre.org> wrote: > This kind of fully automated approach isn't solved yet. OAuth isn't quite > as simple as HTTP Basic and its kin, where the user agent can collect > everything it needs directly and just push it back to the protected URL. In > order for this to truly work, you need to have not just a pointer to the > issuer, but a full dynamic registration and service discovery stack that > the client knows about. For starters, the Client needs to know the > Authorization Endpoint and Token Endpoint for the service, as well as which > flows it supports. You'd probably want to know what kinds of token are > supported, too. The authorization server needs to issue a Client ID and > (probably) Client Secret to the Client to allow it to request tokens at > all. Defining those is out of scope for the core specs, but there's some > new work that's getting started around Host Meta (for discovery) and a > dynamic client registration spec that will address some of the biggest > parts of this. > > -- Justin > > > On 05/15/2012 08:12 AM, Sergey Shishkin wrote: > > 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 listOAuth@ietf.orghttps://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
