Subject: [OAUTH-WG] Guidance on Native Applications in the Framework Spec (was Flowchart for legs of OAuth)

From: Mike Jones <[email-masked]>
Date: Mon, 4 Apr 2011 19:06:24 +0000

One of the results at the OAuth meeting on Friday was that non-normative text describing how to use OAuth with native applications will be restored to the framework draft.  We could start with the text from past drafts, but it can likely be improved upon as well.

Marius, as someone who has extensively deployed an OAuth protocol with native apps, what would you like the draft to say about this?  (Others with actual deployments, please respond as well if you have things to add!)

				Thanks,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Skylar Woodward
Sent: Monday, April 04, 2011 11:54 AM
To: Marius Scurtescu
Cc: Kris Selden; [email-masked]
Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 4 Apr 2011 19:10:36 +0000

So the rewrite of the text was given to Torsten and myself as action items, but welcome others to help out here

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Monday, April 04, 2011 12:06 PM
To: Skylar Woodward; Marius Scurtescu
Cc: Kris Selden; [email-masked]
Subject: [OAUTH-WG] Guidance on Native Applications in the Framework Spec (was Flowchart for legs of OAuth)

				Thanks,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Skylar Woodward
Sent: Monday, April 04, 2011 11:54 AM
To: Marius Scurtescu
Cc: Kris Selden; [email-masked]
Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth

skylar

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 4 Apr 2011 14:26:35 -0700

Just to clarify. Those attending the meeting did not decide. The chairs asked Torsten and Anthony to take the text removed and resubmit it for working group consideration. The text discussed is all non-normative, and is meant as a helpful guide.

As editor, I don't have any objections and think this is a worthwhile effort.

EHL

> One of the results at the OAuth meeting on Friday was that non-normative
> text describing how to use OAuth with native applications will be restored to
> the framework draft.  We could start with the text from past drafts, but it can
> likely be improved upon as well.
> 
> Marius, as someone who has extensively deployed an OAuth protocol with
> native apps, what would you like the draft to say about this?  (Others with
> actual deployments, please respond as well if you have things to add!)
> 
> 				Thanks,
> 				-- Mike
> 
> 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
> 
> 
> >> 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?
> >