Subject: [OAUTH-WG] Implicit vs. Code flow for Native clients

From: Lewis Adam-CAL022 <[email-masked]>
Date: Fri, 8 Jun 2012 13:28:04 +0000

Hi all,

I'm looking for a better understanding of why the code flow is recommended as the preferred OAuth flow, even when used for native (public) clients.

I totally get why it is preferred for confidential clients, as explained in section 1.3.1. of the version 26 of the draft.  The first reason is the ability of the token endpoint to authenticate the client - which doesn't really apply in the case of native (public) clients.  The second reason cited is the ability to communicate the access token directly to the client, without exposing it to the UA and possibly leaking the access token.    This is probably the one where I don't fully understand the security risk.  

In the code flow, the code obviously does flow through the UA, which could also be exposed to malicious clients executing on the device.  And a malicious client that steals this code could exchange it for the access token.  

Now ... I assume the reason it is still recommended is that unlike an access-token, the code can only be used ONCE in exchange for a token, and if a rogue clients grabs it and then the legit clients grabs it and each present it to the token endpoint in attempt to get the token, the token endpoint can detect that it has been compromised (as it has been presented twice) and thus cut the attack short?  Or is there more to it than that?

I'm asking because the implicit flow avoids an additional roundtrip, and my clients will run over (at times) very anemic bandwidths.  I want to fully understand the security implications vs. performance tradeoffs before making a decision.

Tx!
adam

---

From: John Bradley <[email-masked]>
Date: Fri, 8 Jun 2012 10:51:35 -0400

The implicit flow doesn't allow for refresh tokens.

The refresh token mechanism allows for the AS to revoke access to the RS when a relatively short lived access_token expires.

Some people seem to prefer having the RS make a callback to the AS on each access, and not use refresh tokens.  
There tradeoffs each way.   Issuing a non expiring access_token to the client with no way to revoke it is quite likely a bad idea.

I think you are correct that for a native client directly talking to the AS the implicit flow is no more likely to have token exposed than code.

The devil is in the details though, I am not recommending implicit over code, the right one to use will depend on multiple factors.

John B.
On 2012-06-08, at 9:28 AM, Lewis Adam-CAL022 wrote:

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

---

From: Nat Sakimura <[email-masked]>
Date: Sun, 10 Jun 2012 15:21:11 +0900

I guess, in the ideal world, the app provider provide a group
signature for the app and each client establishes individual keys with
AS, but that is not the way current oauth is architected. Maybe the
next step after the current set of the new work items are finished.

=nat via iPhone