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
