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
