Subject: [OAUTH-WG] Breaking change for authorization code flow?

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 26 Feb 2011 14:02:51 +0100

Hi all,

I just noticed a change between draft 11 and 13 I would like to bring to your attention.

Until draft 11, the spec left open whether the client of the authz code grant type had to present a secret or not. It had been a decision of the authz server
and I assume some deployments already work that way (at least our's does).

Accordingly the text for the request to change a code for token is:
"Validate the client credentials (if present) and ensure they match the authorization code."

In drafts 12/13, the text has been changed to:
"Validate the client credentials and ensure they match the authorization code."

Given the assumption that, w/o a dynamic client registration feature, native application cannot securely manage secrets,
this means native apps cannot use the authorization code flow any longer.

The only interactive flows left would be "implicit grant", which is not capable of issuing refresh tokens. Which in turn
means, native app would be forced to acquire access tokens interactively in every session.

Am I right? Or do I just misinterpret the text?

I would suggest to stick to the -11s semantics of the authorization code flow.

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 26 Feb 2011 09:49:15 -0700

I think you are making too much of this.

Section 3.2 clearly states:

  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.

Which covers everything. However, I want the rest of the document to clearly express the expectation that the client is authenticated and lack of such is an exception. This will also make the security consideration section simpler by assuming the client is authenticated.

I don't mind putting this back in if others feel strongly about it, and will take it in as part of the LC review process. I consider this purely editorial.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Torsten Lodderstedt
> Sent: Saturday, February 26, 2011 5:03 AM
> To: OAuth WG
> Subject: [OAUTH-WG] Breaking change for authorization code flow?
> 
> Hi all,
> 
> Until draft 11, the spec left open whether the client of the authz code grant
> type had to present a secret or not. It had been a decision of the authz
> server and I assume some deployments already work that way (at least our's
> does).
> 
> Given the assumption that, w/o a dynamic client registration feature, native
> application cannot securely manage secrets, this means native apps cannot
> use the authorization code flow any longer.
> 
> The only interactive flows left would be "implicit grant", which is not capable
> of issuing refresh tokens. Which in turn means, native app would be forced
> to acquire access tokens interactively in every session.
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 27 Feb 2011 13:45:39 +0100

> I think you are making too much of this.

glad to hear :-) I just want to make sure native apps are OAuth 1st 
class citizens. The aibility to issue refresh tokens to such clients is 
a key feature, which is by no meaning an exception. Even if they cannot 
be authenticated.

regards,
Torsten.