Re: [OAUTH-WG] Flowchart for legs of OAuth

Does section 3.2 help you?
"In addition, the authorization server MAY allow unauthenticated access token requests when the client identity does not matter (e.g. anonymous client) or when the client identity is established via other means."

Phil
phil.hunt@oracle.com

On 2011-04-04, at 1:09 PM, Justin Richer wrote:

> Agreed - we are planning to use the auth-code flow for native apps and
> have no immediate plans to use implicit mode for native clients, either.
> We'd be using the auth-code flow with a client id only and no client
> secret, which I think is the pattern that everyone else is planning to
> follow.
> 
> -- justin
> 
> On Mon, 2011-04-04 at 14:54 -0400, Skylar Woodward wrote:
>> I agree with Marius' points. We plan to support the auth-code flow for native apps as well.  There is no reason why native apps can't perform a successful auth-code flow, they just do so without client credentials.  However, the spec doesn't make it clear that this is viable option.
>> 
>> skylar
>> 
>> 
>> On Apr 4, 2011, at 2:29 PM, Marius Scurtescu wrote:
>> 
>>> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden <kris.selden@gmail.com> wrote:
>>>> A typical iPhone app cannot be shipped with a client secret and rightly or wrongly users expect to only have to enter their credentials once.
>>>> 
>>>> What is the best profile to use for an app that can't have a client secret and needs a refresh token or a long lived access token?
>>> 
>>> The authorization code grant, aka web server flow.
>>> 
>>> The spec is misleading in this respect IMO.
>>> 
>>> Marius
>>> _______________________________________________
>>> 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
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth