Subject: Re: [OAUTH-WG] Draft -12 feedback deadline

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Feb 2011 09:34:34 -0700

> -----Original Message-----
> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Wednesday, January 26, 2011 12:09 PM

> - 4.3. Resource Owner Password Credentials. The 3rd paragraph states that
> the client MUST discard the credentials once it obtains an access token. I
> think it SHOULD discard once it obtains a *refresh* token.

Since this MUST cannot be confirmed, it serves as a community educational tool more than anything else. I rather leave it without conditions.
 
> - 4.5. Extensions. For new grant types, we are not using a registry. Is that OK?

No need. The registry is only to prevent name collisions and since we are using URIs, they already have built-in namespaces.
 
> - 5.2. Error Response. The fist part of the first paragraph talks about 401 and
> client credentials in the Authorization header. Since this was dropped from
> core, this looks strange.

This is specific to client authentication, not grant verification or protected resources. I'll clarify.

EHL

---

From: Phil Hunt <[email-masked]>
Date: Wed, 16 Feb 2011 09:00:32 -0800

Re: 4.3. This could be something to put in security considerations.  Since there will be reasonable cases where for example a password hash is retained.  And as indicated by Eran, this is a best practice rather then an inter-op issue.

Phil
[email-masked]

On 2011-02-16, at 8:34 AM, Eran Hammer-Lahav wrote:

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Feb 2011 10:00:48 -0700

> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
> 
> - 4.1. Authorization Code. It is stated that authorization code is suitable for
> clients that can hold a secret. Not necessarily true, it is the best flow for
> native apps, for example.

While the authorization code *can* be used without client authentication, it was designed explicitly for that use case. By defining it as such, we make the security consideration section significantly simpler and more specific.

Now, this does not prevent using it without client authentication. Note that this is prose and not normative language.

I rather not change this. I think using the ability of the client to authenticate with confidential credentials has been a huge issue for OAuth 1.0 understanding and implementers and this is the simplest way to address it.

At some point, trying to make every single word be 100% compatible with every conceivable use case makes the specification unusable.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Feb 2011 10:01:41 -0700

> From: Skylar Woodward [mailto:[email-masked]]
> Sent: Thursday, January 27, 2011 2:37 AM

> -- 3.1.1, 4.1.2, and Out-of-Band flows
> 
> It is an important consideration for us that clients that cannot capture a
> redirect from the user-agent be able to use authentication flow. In the past
> this has been dubbed and Out-of-Band (OOB) flow. However, the
> reorganization of the document clearly marks out both Auth and Implicit as
> flows reserved for clients "capable of receiving incoming requests (via
> redirection) from the authorization server."  This language makes these
> incompatible with OOB clients.  In addition, other language inhibits this use:

No, it is just guidance. As defined, these are not appropriate for OOB clients, but with minor adjustments, such as the definition of a special URN redirection URI, can be made suitable.
 
EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 16 Feb 2011 09:04:32 -0800

> At some point, trying to make every single word be 100% compatible with every conceivable use case makes the specification unusable.

Yes, I understand. But Native Apps have no appropriate flow now, and
they started the whole protocol.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Feb 2011 10:33:13 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Richer, Justin P.
> Sent: Thursday, January 27, 2011 12:05 PM

> 1.2
> 
> "Tokens may be pure capabilities." To a non-security-engineer such as
> myself, this bit reads very oddly on its own. I understand that "capability" has
> another meaning in the security world, so can we either reference that
> definition or give a small prose example, like "capabilities, such as ...".

I dropped this. This means nothing to most people. I have no objection for this to be added in the security considerations section.
 
> 1.3
> 
> Should these introductions link down to their implementation sections?
> Seems like a useful xref.
> 
> 1.3.2, 4.2

Nah. I want people to read the introduction as a whole, then just use the rest as reference. Jumping between sections is just confusing.

> I'm not sold on calling this "Implicit", though "user agent" and "direct" aren't
> much better.

It's descriptive.

> 2.
> 
> Should we strengthen the first "SHOULD NOT" to a "MUST NOT", since this is
> about assumptions of security made by the AS? This is possibly bikeshedding
> as the AS could always still say "We know that the secret-storage security of
> some clients might be bad but that's OK."

I actually changed it to lowercase since it is not really normative.

> 3.2
> 
> Can we make the token endpoint MUST support POST and MAY support
> GET? I understand the arguments for favoring POST, but they don't always
> apply to all environments. (Brought this up a while ago, seems like it's not a
> breaking change to allow.)

It applies to the web as a whole. What you do internally is your business... Requiring POST removes the need to write security consideration about the issues with GET.

> 6.
> 
> I'd like to see a paragraph on redelegation practices, but I'm not sure it
> belongs in the core as it's really more of a way of *using* refresh tokens and
> scopes in a slightly different way than it is really a *new* thing. All the
> mechanisms are there to support it, a recipe just hasn't been written out for
> it. Is there desire for an extension doc for this?

>From my experience, writing a draft works better than asking for interest. I am sure you'll find an audience.
 
EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Feb 2011 11:43:08 -0700

> Sent: Wednesday, February 16, 2011 9:05 AM

> Yes, I understand. But Native Apps have no appropriate flow now, and they
> started the whole protocol.

I am not sure "they started the whole protocol" (it was more like OpenID in Twitter API), but either way, why can't they use the implicit grant type? That's where the specification is guiding them towards.

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 16 Feb 2011 10:58:29 -0800

> I am not sure "they started the whole protocol" (it was more like OpenID in Twitter API), but either way, why can't they use the implicit grant type? That's where the specification is guiding them…

That would be the old User-Agent flow?

That's terrible for native apps, native apps need long lived credentials.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Feb 2011 11:59:07 -0700

Yes.

> Sent: Wednesday, February 16, 2011 10:58 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> > I am not sure "they started the whole protocol" (it was more like OpenID in
> Twitter API), but either way, why can't they use the implicit grant type?
> That's where the specification is guiding them towards.
>

---

From: William Mills <[email-masked]>
Date: Wed, 16 Feb 2011 11:06:54 -0800

Token endpoint with username/password credential doesn't solve this?  Depends on the auth scheme of course, but Bearer should provide a solution?

> Of Marius Scurtescu
> > I am not sure "they started the whole protocol" (it was more like
> OpenID in Twitter API), but either way, why can't they use the implicit
> grant type? That's where the specification is guiding them towards.
>

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 16 Feb 2011 11:14:08 -0800

> Token endpoint with username/password credential doesn't solve this?  Depends on the auth scheme of course, but Bearer should provide a solution?

Not at all, in most case native apps must use the browser based 3-legged dance.

Marius

---

From: Brian Campbell <[email-masked]>
Date: Wed, 16 Feb 2011 13:07:24 -0700

Exactly Marius, and in most cases the app will want to procure a
refresh token as a result of the dance so it won't have to put the
user though the authorization process again and again.  Unless I'm
mistaken, the implicit grant provides no means of obtaining a refresh
token (http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2.2).
 So unless the access tokens themselves are extremely long lived, the
implicit grant flow doesn't seem very useful to native clients.

I've heard a number of people suggest the native client -> implicit
grant thing but it doesn't make sense to me.  Is there something I'm
not seeing?

---

From: Justin Richer <[email-masked]>
Date: Wed, 16 Feb 2011 15:20:34 -0500

The implicit grant still requires a redirect of some kind, so many 
native apps can just as easily use the web server flow as the implicit 
flow. I personally don't see how the implicit flow is better suited than 
the web flow in this case. However, neither of these are ideally suited 
for native apps without a few tricks, which is the native apps extension 
that Marius is working on, to get the token back to the native app. From 
what I can see, the real question here is dealing with cases where a 
redirect doesn't actually make any sense. In those cases, I'd rather see 
a separate flow profiled end to end than to have hacks like the 
"uri:oob" put in place to patch it into an existing spot.

  -- Justin

On 2/16/2011 3:07 PM, Brian Campbell wrote:
>> On Wed, Feb 16, 2011 at 11:06 AM, William Mills<[email-masked]>  wrote:

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Feb 2011 13:28:43 -0700

The reason why we don't return a refresh token in the implicit grant is exactly because there is no client authentication... These are all well-balanced flows with specific security properties. If you need something else, even if it is just a tweak, it must be considered a different flow. That doesn't mean you need to register a new grant type, just that you are dealing with different implementation details unique to your server.

EHL

> Of Brian Campbell
> Sent: Wednesday, February 16, 2011 12:07 PM
> To: Marius Scurtescu
> Cc: OAuth WG
> Exactly Marius, and in most cases the app will want to procure a refresh
> token as a result of the dance so it won't have to put the user though the
> authorization process again and again.  Unless I'm mistaken, the implicit grant
> provides no means of obtaining a refresh token
> (http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2.2).
>  So unless the access tokens themselves are extremely long lived, the implicit
> grant flow doesn't seem very useful to native clients.
> 
> I've heard a number of people suggest the native client -> implicit grant thing
> but it doesn't make sense to me.  Is there something I'm not seeing?
> 
> >> Token endpoint with username/password credential doesn't solve
> this?  Depends on the auth scheme of course, but Bearer should provide a
> solution?
> >

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 16 Feb 2011 13:38:45 -0800

On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> The reason why we don't return a refresh token in the implicit grant is exactly because there is no client authentication...

Not sure that's the main reason. AFAIK it is because the response is
sent through the user-agent and it could leak.

> These are all well-balanced flows with specific security properties. If you need something else, even if it is just a tweak, it must be considered a different flow. That doesn't mean you need to register a new grant type, just that you are dealing with different implementation details unique to your server.

The Authorization Code flow, with no client secret, is perfectly fine
for Native Apps IMO.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Feb 2011 14:57:35 -0700

Feel free to propose alternative preamble for the implicit and authorization code sections, describing the characteristics of what they are good for. It should fit in a single paragraph. Such a proposal would fit right in with last call feedback to -13.

EHL

> Sent: Wednesday, February 16, 2011 1:39 PM
> To: Eran Hammer-Lahav
> Cc: Brian Campbell; OAuth WG
> > The reason why we don't return a refresh token in the implicit grant is
> exactly because there is no client authentication...
> 
> Not sure that's the main reason. AFAIK it is because the response is sent
> through the user-agent and it could leak.
> 
> 
> > These are all well-balanced flows with specific security properties. If you
> need something else, even if it is just a tweak, it must be considered a
> different flow. That doesn't mean you need to register a new grant type, just
> that you are dealing with different implementation details unique to your
> server.
> 
> The Authorization Code flow, with no client secret, is perfectly fine for Native
> Apps IMO.
> 
> Marius

---

From: Mark Mcgloin <[email-masked]>
Date: Fri, 18 Feb 2011 11:49:24 +0000

Marius

Isn't the risk of the refresh token leaking the same as the risk of the
access token leaking, i.e. why not provide both? IMO, the refresh token
just provides a server side mechanism for revoking access, where resource
servers are distributed, through having short lived access tokens

Of course, the refresh access token flow currently requires a secret so
would need to be changed or alternative flow introduced. Will wait for
details of how auth code flow can be used

Mark
e-mail: [email-masked]

[email-masked] wrote on 16/02/2011 21:38:45:

> Marius Scurtescu <[email-masked]>
> Sent by: [email-masked]
>
> 16/02/2011 21:38
>
> To
>
> Eran Hammer-Lahav <[email-masked]>
>
> cc
>
> OAuth WG <[email-masked]>
>
> Subject
>
> Re: [OAUTH-WG] Draft -12 feedback deadline
>
> > The reason why we don't return a refresh token in the implicit
> grant is exactly because there is no client authentication...
>
> > These are all well-balanced flows with specific security
> properties. If you need something else, even if it is just a tweak,
> it must be considered a different flow. That doesn't mean you need
> to register a new grant type, just that you are dealing with
> different implementation details unique to your server.
>

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 18 Feb 2011 09:40:21 -0800

On Fri, Feb 18, 2011 at 3:49 AM, Mark Mcgloin <[email-masked]> wrote:
> access token leaking, i.e. why not provide both?

Sure, but refresh tokens never die.

> IMO, the refresh token

The flow is not changing. For native apps the client secret can either
be declared optional, or a "well known secret" can be issued for
native apps.

The authorization server can also insist that each native app has a
unique secret and it must guard it, that may or may not make sense.

Marius

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 26 Feb 2011 13:39:13 +0100

Am 18.02.2011 18:40, schrieb Marius Scurtescu:
> On Fri, Feb 18, 2011 at 3:49 AM, Mark Mcgloin<[email-masked]>  wrote:
>> Marius
>>

One can replace the refresh token with every refresh request, so the 
impact of a refresh token leakage could be reduced to that of a leaked 
access token.

I'm in favour to add the refresh token parameter to the implicit grant 
flow as it would make it more useable for native apps. On the other 
hand, requirements of the authorization code flow could be strengthened 
to require client authentication.

regards,
Torsten.

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 28 Feb 2011 15:16:09 -0500

+1

Igor

Torsten Lodderstedt wrote:
> ...
> flow as it would make it more useable for native apps.

> ....

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 28 Feb 2011 14:58:03 -0800

>> flow as it would make it more useable for native apps.

I think it is much safer to go with refresh tokens only sent
indirectly through an authorization code swap.

Implicit grant with refresh token also has no client secret swap and
makes things worse by passing the refresh token through the browser.

Marius

---

From: Phil Hunt <[email-masked]>
Date: Mon, 28 Feb 2011 15:18:12 -0800

Given these questions, I am wondering, why does the Implicit Grant flow NOT have an authorization code step?  Having one, would keep architecture of AS and TS clearly separate.

One down side is that issuing of access/refresh token would now have to be opened to SHOULD authenticate the client from MUST.

What was the original case for this flow?  That should point us as to why the separate flow and whether refresh makes sense given the higher risks of the implicit flow.

Phil
[email-masked]

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 28 Feb 2011 18:27:48 -0500

Cannot help harping... It is exactly this type of a question that Phil 
asked that makes a document on the use cases necessary!

Igor

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 28 Feb 2011 18:24:07 -0700

One more round trip is often too slow.

EHL

> Of Phil Hunt
> Sent: Monday, February 28, 2011 3:18 PM
> To: Marius Scurtescu
> Cc: OAuth WG
> Given these questions, I am wondering, why does the Implicit Grant flow
> NOT have an authorization code step?  Having one, would keep architecture
> of AS and TS clearly separate.
> 
> One down side is that issuing of access/refresh token would now have to be
> opened to SHOULD authenticate the client from MUST.
> 
> What was the original case for this flow?  That should point us as to why the
> separate flow and whether refresh makes sense given the higher risks of the
> implicit flow.
> 
> Phil
> [email-masked]
> 
> 
> 
> 
> >>> I'm in favour to add the refresh token parameter to the implicit
> >>> grant flow as it would make it more useable for native apps.
> >

---

From: Skylar Woodward <[email-masked]>
Date: Tue, 1 Mar 2011 03:28:06 +0100

I had assumed a use case for this was an entirely browser-based client. Such a client would be limited to same-host requests. Providing a proxy to make token requests just opens the possibility of abuse of client proxies with poor security practices - and for no added value. If a client can't secure credentials, there's no point in a second round trip. As such, simplify the model and, in the process, emphasize the loss of of a layer of security in the flow.

In principle, I favor reserving separate flows for credential vs. credential-less apps. However, in practice, I see providers evangelizing one flow when there are a mix of apps with credentials and those without (eg, mix of device & hosted apps in the ecosystem) and thus no need to restrict the code flow only to clients with secrets. One flow is enough complication when there is provider-specific complexity to explain as well. The implicit flow, then, seems appropriate for providers who never issue secret client credentials.

Better use cases anyone?