Subject: Re: [OAUTH-WG] Text for Native Applications

From: Brian Eaton <[email-masked]>
Date: Wed, 1 Jun 2011 00:00:08 -0700

On Tue, May 31, 2011 at 11:47 PM, Kris Selden <[email-masked]> wrote:
> If a provider chooses to do that though, in the attack you described, they could still revoke the refresh token to stop the abuse when it is discovered, and that is still easier in my opinion than rotating a client secret but yes, allowing that does make the client secret pointless for refreshing tokens.

The attack I am describing is against a web server, so what you are
saying is not true.

We should talk about installed apps (no real client secret)
differently than we talk about web servers.  They are different
problems.

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 1 Jun 2011 00:08:00 -0700

On 5/31/11 11:56 PM, "Brian Eaton" <[email-masked]> wrote:

On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore
<[email-masked]> wrote:
> It's not entirely necessary; I'm just having a tough time figuring out any
> practical difference between the implicit grant flow, and the webserver flow
> with no credentials.   In general I agree with your points, but I think we
> have a similar, perhaps worse, scenario with relaxing the need for
> credentials on the web server flow.

No doubt. =)  I think it's unfortunate that the spec was changed to
make the client credentials optional for the web server flow.  As you
say, it's a security problem for web apps.  We are treating the client
secret as mandatory in our deployments, and basically everyone who
deploys the web server flow should do the same.  It's a shame the spec
is so vague on this point.

This is one reason we've favored implicit for native apps.

The root cause of the spec ambiguity was disagreement over how to
handle secrets for installed applications.  I can think of three paths
forward.

- split out "installed app flow" from "web server flow".  Use a new
grant type.  (DON'T switch installed apps to use the "implicit" grant
type.  That doesn't work either, because it doesn't return a
long-lived credential.  DON'T have the implicit grant type return a
refresh token directly, either, since that causes serious security
problems for real web apps that can keep client secrets.)

Our approach to this issue has been to avoid returning refresh tokens to web URLs when using the implicit grant.   We only support returning to one controlled URL on our server, or to a custom scheme url.   It's bit tough to explain doc for developers though.

- make the client secret mandatory, but tell people who are offended
by client secrets in installed apps to use the string "notasecret" for
all installed apps.

Toyed with this idea.

-cmort

- ignore the problem and leave the spec vague and insecure.

> In terms of your example, wouldn't basic XSRF protection in the state param protect?

Nope.  Assume the following scenario:
- bad guy has stolen refresh token
- client web server has detected attack and changed their client secret
- bad guy wants to find a way to keep using the refresh token

If refresh tokens are returned without client authentication, the bad
guy can do it as follows:
- visit client.  log in as account badguy1234.
- client redirects to authorization server, including state=1234
- bad guy ignores redirect to authorization server, visits client
callback server with refresh_token=stolen&state=1234
- client picks up stolen refresh token and associates it with badguy1234.
- whenever badguy1234 visits the client web site, he can see data from
the stolen refresh token.

Cheers,
Brian

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 01 Jun 2011 09:15:24 +0200

I'm getting confused. This thread is about native apps. So why discuss 
security considerations for web apps here?

regards,
Torsten.

Am 01.06.2011 09:00, schrieb Brian Eaton:
> On Tue, May 31, 2011 at 11:47 PM, Kris Selden<[email-masked]>  wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Eaton <[email-masked]>
Date: Wed, 1 Jun 2011 00:16:29 -0700

On Wed, Jun 1, 2011 at 12:08 AM, Chuck Mortimore
<[email-masked]> wrote:
> This is one reason we’ve favored implicit for native apps.

OK, so are you using the implicit grant for both web apps and native
apps...?  I'm trying to figure out if you need two flows are three.

- web server flow
   used with real secret client credentials
   gives out long-lived tokens

- native app flow
   doesn't have real secret client credentials
   gives out long-lived tokens

- implicit flow for javascript apps
   gives out short-lived tokens based on callback URLs

(We need all three of those flows, BTW, plus at some point we'll get
around to implementing a javascript flow that returns authorization
codes, and a web server flow that provides short-lived credentials...
but those are lower priority.)

---

From: Brian Eaton <[email-masked]>
Date: Wed, 1 Jun 2011 00:20:30 -0700

> security considerations for web apps here?

They overlap because they both use refresh tokens. =/  When people
propose changes that impact refresh tokens, it impacts both flows and
we need to be careful it doesn't create new problems.

For example: Chuck proposed returning a refresh token on the implicit
grant type, for use by native apps.  That would screw up the security
considerations for javascript web apps that rely on the implicit grant
type.

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 1 Jun 2011 00:41:14 -0700

We have have need for all three types

For web apps, we use web server flow with credentials, and can escalate some capabilities for the client since we can be more assured we're talking to the actual client.

For native apps, we support:

 1.  the implicit grant ( but we wont give out a refresh token to web/js based applications )
 2.  the web server flow with a user+client_id specific secret which we can issue through an admin controlled provisioning process.  In this case we can also escalate capabilities as we're reasonably sure we're talking to an instance of the client.

For JS Apps we support the implicit grant with no refresh token

-cmort

On 6/1/11 12:16 AM, "Brian Eaton" <[email-masked]> wrote:

- web server flow

- native app flow

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 1 Jun 2011 00:42:52 -0700

On 6/1/11 12:20 AM, "Brian Eaton" <[email-masked]> wrote:

Not entirely what I'm suggesting, but looking back I wasn't clear.   My Bad.  See my description of what we currently support that I just sent.

-cmort

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 01 Jun 2011 09:47:11 +0200

Am 01.06.2011 08:56, schrieb Brian Eaton:
>> It’s not entirely necessary; I’m just having a tough time figuring out any

So far every grant type represented a different protocol flow (not 
client type). Why do you want to define different grant types for 
basically the same flow but different client 
identification/authentication policies? What if a service provider is 
able to securely deploy instance-specific secrets to its native apps 
(e.g. in intranet scenarios - see Chuck's posting). Shall it use the 
"web server flow" then? The current text keeps client authentication and 
the grant type orthogonal. I would suggest to stick to this approach.

> by client secrets in installed apps to use the string "notasecret" for

How is that any different from just not using a secret from a security 
perspective?

> - ignore the problem and leave the spec vague and insecure.

Could you please describe what you consider "insecure"? I think we have 
the challenge to defining a secure protocol while supporting the needs 
of different client types.

Past versions of the spec entirely focused on client secrets as 
mechanism to validate a client's identity. This created the false 
impression that native apps either
1) must use the implicit grant type (which does not support refresh 
tokens), or
2) use the authz code grant type in conjunction with a (weakly/none 
protected) secret in order to comply with the text of the specification.
3) It is also interesting to note that people have started to think 
OAuth does not support native apps!

(1) results in a sub-optimal user experience since the app has to go 
through the (interactive) authz cycle with every startup or
       the authz server issues long-living a access tokens (?) or
      (even worse) the authz server automatically issue access tokens 
for sub-sequent requests by the same client (how to determine "same"?).
(2) creates a _false_ impression of security because the authz server 
authenticated the clients. But the authorization server _must not_ rely 
on such a secret for validating the client's identity.

The security consideration section clearly states this now.

regards,
Torsten.

>> In terms of your example, wouldn’t basic XSRF protection in the state param protect?

---

From: Brian Eaton <[email-masked]>
Date: Wed, 1 Jun 2011 00:50:46 -0700

OK, so you've got some native apps using the web server flow, and some
using a modified version of the implicit grant that includes a refresh
token.

I hate to say it, but I think this whole thing would be a lot simpler
if we had a grant type called "native app".  Instead everyone is
adding unspecified parameters or making parameters optional so that
they can support native apps properly.

On Wed, Jun 1, 2011 at 12:41 AM, Chuck Mortimore
<[email-masked]> wrote:
> For web apps, we use web server flow with credentials, and can escalate some
> capabilities for the client since we can be more assured we’re talking to
> the actual client.
>
> the implicit grant ( but we wont give out a refresh token to web/js based
> applications )
> the web server flow with a user+client_id specific secret which we can issue
> through an admin controlled provisioning process.  In this case we can also
> escalate capabilities as we’re reasonably sure we’re talking to an instance
> of the client.
>

---

From: Brian Eaton <[email-masked]>
Date: Wed, 1 Jun 2011 01:18:54 -0700

On Wed, Jun 1, 2011 at 12:47 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> Could you please describe what you consider "insecure"?

As an example, optional client authentication in the authorization
code flow makes the web server flow much less secure.  But it's
permitted by the spec.

The confusion you mention about how to support native apps is also
going to create security problems.  You mentioned the risks of
auto-approving token requests from native apps.

> I think we have the
> challenge to defining a secure protocol while supporting the needs of
> different client types.

+1 to that.

> Past versions of the spec entirely focused on client secrets as mechanism to
> validate a client's identity. This created the false impression that native
> apps either...

<snip analysis of the consequences of the spec language and how the
security considerations tries to fix the spec>

I think your efforts to clear this up in the security considerations
are so admirable that they should move into the main body of the spec
instead. =)

In particular, I think the spec should say that:

- native apps always use the authorization code grant
- if authorization servers are comfortable issuing client secrets to
native apps, they may do so
- if authorization servers are not comfortable issuing client secrets
to installed apps, they may use a blank or well-known client secret.

That would let us simplify the authorization code protocol and the
refresh token protocol, since parameters would move from
sometimes-they-are-required-sometimes-not to being required.

It would also let us have a clear direction to point people who want
to support native apps.

And it would meet the requirement of having a clear path forward for
people who don't want to trust native apps to keep secrets really
secret.

---

From: Doug Tangren <[email-masked]>
Date: Wed, 1 Jun 2011 04:22:01 -0400

> if we had a grant type called "native app".

+1. stop muddying the waters

---

From: Skylar Woodward <[email-masked]>
Date: Wed, 1 Jun 2011 10:41:22 +0200

> people who don't want to trust native apps to keep secrets really

I just want to re-iterate my point from a few months ago that it necessarily helpful to draw the line for secret protection between native and non-native apps. For our users we're going to use the terms VERIFIABLE and FORGEABLE with respect to client identity. We'll help users determine if the can keep secrets or not. Developers who understand they can't keep secrets will understand their app identity to be forgeable (and thus they will not be issued secrets).  Most native apps will be forgeable thus we'll point them in this direction, but there will be exceptions (especially with partners with protected app distribution).

My point is, we should focus on having developers understand if and why their app can't keep secrets, not merely thinking "oh, this is app is native so I have to do it this way."

Verifyable and Forgeable were the best terms we've come up with so far in attempt to put a label on "apps that can keep secrets" and "apps that can't keep secrets," respectively.

There are some aspects of OAuth flow that are unique to native apps (mostly on account of the app not executing in a user agent), but ability to keep secrets is not a property shared or exclusive to all native apps.  (Some web apps might not be able to keep secrets based on open development or deployment model).

---

From: "William J. Mills" <[email-masked]>
Date: Wed, 1 Jun 2011 09:01:57 -0700 (PDT)

> The biggest difference between a refresh token and a non-expiring access token is that 
> the refresh token
 needs to be verified by the authorization server only whereas the 
> access token needs to be verified by the resource servers.

I just want to call out that use of short lifed access tokens with long lived refresh tokens allows your login/auth/refresh servers to be a single point of control for expiring/invalidating tokens.  A very good thing. 

________________________________
From: Kris Selden <[email-masked]>
To: Doug Tangren <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Tuesday, May 31, 2011 11:45 PM
Subject: Re: [OAUTH-WG] Text for Native Applications

I would suspect that many users are overwhelmed when authorizing many fine grained scopes and don't fully understand the risks.  Many popular sites ask for offline access straight away upon connecting to Facebook (Foursquare, Quora, Instagram, etc).  This offline access token, has a higher chance of being exposed, like if you use the cookie: true option in the Facebook JS SDK (which Foursquare does), which sets a Javascript accessible non secure cookie on your domain which now means that if Foursquare makes a non secure http request to foursquare.com a non expiring bearer token will go out in plaintext.  Foursquare is https only but many sites that use the JS SDK aren't.

The biggest difference between a refresh token and a non-expiring access token is that the refresh token needs to be verified by the authorization server only whereas the access token needs to be verified by the resource servers.

-------

Here is the rationale in Scalable OAuth Extension (http://wiki.oauth.net/w/page/12238549/ScalableOAuth#RationaleforRenewableAccessTokensSessions) which was a predecessor to OAuth WRAP and OAuth 2:

Rationale for Renewable Access Tokens (Sessions)

Many Service Providers have the concept of a Session credential with a finite lifetime. Consumers authenticate with the Service Provider's Authentication Service to obtain a Session credential to access the Service Provider's protected resources. When the Session credential expires, the consumer is able to obtain a new Session credential by re-authenticating with the Authentication service. The primary benefit to this architecture is that Session credentials do not need to be revocable if they expire quickly, and that protected resources can be returned without a database lookup to verify that the consumer is still authorized.

Rationale for Auth Session (aka Refresh Secret)

Service Providers often run their Authentication Service separately from other protected resources. The Authentication Service is usually strictly monitored and controlled, while other Protected Resources may be running relatively new and unproven code.

In the event that a Protected Resource is compromised (the SP gets hacked), it is desirable to prevent the intruder from being able to continue to compromise the system after the vulnerability has been fixed. Issuing credentials with a finite lifetime limits the duration that the intruder can continue to use compromised credentials. Issuing a credential to a Consumer that is not known by the Protected Resource but is known by the Authentication Service can enable an Service Provider to revoke access to an intruder without requiring consumers to be reauthorized.

------

Another related issue with Native Apps like iPhone Apps that can't be shipped with a client secret is the end user's expectation to stay "logged in."  

On May 31, 2011, at 7:12 PM, Doug Tangren wrote:

>
>"offline_access permission."
>
>
>If I read that right, that says the user has to opt into the access_token not expiring. I believe this may be the smarted solution for now because it uses the scope parameter to gain this additional access which is using the actual protocol parameters as intended instead of hacking around them.

---

From: "William J. Mills" <[email-masked]>
Date: Wed, 1 Jun 2011 09:11:31 -0700 (PDT)

> - native apps always use the authorization code grant

I don't like this if it means I can't use passwrd grant for stuff like IMAP clients.

________________________________
From: Brian Eaton <[email-masked]>
To: Torsten Lodderstedt <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Wednesday, June 1, 2011 1:18 AM
Subject: Re: [OAUTH-WG] Text for Native Applications

+1 to that.

---

From: Brian Eaton <[email-masked]>
Date: Wed, 1 Jun 2011 09:48:35 -0700

> I don't like this if it means I can't use passwrd grant for stuff like IMAP

Sorry, didn't mean to suggest that password grants would go away.  The
business need is clearly there, no sense in forbidding it if people
are going to do it anyway. =)

---

From: Brian Eaton <[email-masked]>
Date: Wed, 1 Jun 2011 09:54:07 -0700

> Verifyable and Forgeable were the best terms we've come up with so far in attempt to put a label on "apps that can keep secrets" and "apps that can't keep secrets," respectively.

You might be on to something there.  There are two ways clients are
authenticated in the spec.

- client credentials
- registered callback URLs

People are combining them in interesting ways.  And there is stuff
outside the spec, such as the app-to-app authentication built into
smart phone platforms.  (This is used heavily in the facebook
developer platform.  We use it on Android, not on iPhone yet.)

I haven't tried it yet, but I suspect organizing the security
considerations based on how your client authenticates would be
constructive.

> (Some web apps might not be able to keep secrets based on open development or deployment model).

Can you clarify what you mean by this?

What flows are you using for those apps?

---

From: Dave Nelson <[email-masked]>
Date: Wed, 1 Jun 2011 13:17:16 -0400

> Most native apps will be forgeable ...

I don't understand the rationale behind this assertion.  Would you
please point me to the discussion that elaborates on this point.
Thanks!

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Skylar Woodward <[email-masked]>
Date: Wed, 1 Jun 2011 21:17:43 +0200

> Can you clarify what you mean by this?

Simple really, I just mean for some developers it might be more important to have an open development model (eg, over github) than to secure secrets. Rather than request and manage a secret for their project, they just choose to make the project a forgeable app. Let's say it's a Rails app deployed to Heroku and for convenience the team doesn't want to add a build step where a protected secret is brought down from a private repo. It's not a native app, but because of how the team works they can't (or won't) secure a secret. What's in production is exactly whats in a public github branch.

Systems like Heroku are blurring the line between source control and deployment. So you can imagine 3rd party apps, especially voluntary contributions and hack day output being totally transparent from code to server. For some web apps it just won't be a priority to secure a secret. That's all I'm implying.

---

From: Skylar Woodward <[email-masked]>
Date: Wed, 1 Jun 2011 21:24:14 +0200

The group is operating under the assumption that most native apps are publicly deployed or that copies of the app bundle/binary can at least be obtained by a malicious party. Whether and open system or a high protected system like Playstation 3 its always possible for the attacker to disassemble the program and obtain the secret. The secret is the key to an app proving its identity, so as soon as an attacker obtains the secret it can forge the identity of an app in so far as the OAuth auth server is concerned.

---

From: Dave Nelson <[email-masked]>
Date: Wed, 1 Jun 2011 15:43:57 -0400

> The group is operating under the assumption that most
> native apps are publicly deployed or that copies of the
> app bundle/binary can at least be obtained by a malicious
> party.

Agreed.

> ... its always possible for the attacker to disassemble the
> program and obtain the secret.

Always possible?  In theory, perhaps.  As with any threat analysis, it
depends on the resources available to the attacker and the motivations
for mounting the attack.  I firmly believe that secrets can be
sufficiently obfuscated in code delivered in binary format without the
benefit of a symbol table, so as to be sufficiently resistant to
discovery via disassembly by attackers you'd expect to encounter in a
typical commercial environment.  I'm not talking about printable
strings stored in contiguous memory.

I think it's important, for a number of use cases, some of them of
particular interest to me, for an application to be able to use this
form of identification, when sufficient care has been taken to
mitigate the threat model for the intended use.  I'd rather see the
risks inherent in providing secure storage of application credentials
thoroughly discussed in the Security Considerations section, rather
than discouraging it's use altogether in the normative protocol
definition sections of the draft.  I agree that there are many
deployment scenarios in which secrets or passwords would not be an
appropriate method of client identification, but I see some in which
is clearly would be appropriate.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Skylar Woodward <[email-masked]>
Date: Wed, 1 Jun 2011 22:07:17 +0200

> typical commercial environment.  I'm not talking about printable

I have empirical evidence to support this. At Yahoo! we devised one of the most complex systems I've ever seen in a publicly distributed program (Messenger). It was disassembled in 3 days. Scott Renfro (now over with David at Facebook) and likely Bill Mills can also vouch for the difficulty of this having also studied the case well.

Moreover if a hardware-enforced system like that of Playstation 3 can be broken, then so can most systems. The PS3 protection mechanisms are/were very sophisticated.

Even if a system is not yet cracked or is very hard, you have to assume it can be cracked. History has shown this to be true nearly without exception - at least to the point it is not worth considering for the OAuth use cases.

skylar

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 1 Jun 2011 13:59:36 -0700

We don't at all this recommend this type of deployment model for Heroku ( or any platform for that manner ).     We support injecting environment variables at runtime to avoid this problem.

Example:

$ heroku config:add S3_KEY=8N029N81 S3_SECRET=9s83109d3+583493190
Adding config vars:
  S3_KEY    => 8N029N81
  S3_SECRET => 9s83109d3+583493190
Restarting app...done.

AWS::S3::Base.establish_connection!(
  :access_key_id     => ENV['S3_KEY'],
  :secret_access_key => ENV['S3_SECRET']
)

I know Heroku isn't your specific gripe here, but I think it's important that we focus on providing guidance and a secure path for teams and platforms that are doing the right thing.

-cmort

On 6/1/11 12:17 PM, "Skylar Woodward" <[email-masked]> wrote:

---

From: Skylar Woodward <[email-masked]>
Date: Thu, 2 Jun 2011 01:20:15 +0200

Sure, but at the same time, imagine the context of a hackathon event where people certainly make use of OAuth APIs and put very low priority on security. It's bound to happen (and in fact, quick experimental apps like these often consume the bulk of registered client IDs - as opposed to sustained efforts with significant resources). Such apps should see themselves as forgeable and not able (or willing) to keep secrets.

But your point is valid. Apps that *can* keep secrets should make the effort to do so and providers should encourage this behavior for most apps.

At the same time I don't see much difference between building a native client or a secret-less web client, so long as the clients enjoy equivalent (lack of) privilege/trust and precautions on a part of the provider. For our provider we reserve some types of access only to clients that can keep secrets.

On Jun 1, 2011, at 10:59 PM, Chuck Mortimore wrote:

> We don’t at all this recommend this type of deployment model for Heroku ( or any platform for that manner ).     We support injecting environment variables at runtime to avoid this problem.
> 
> Example:
> 
> I know Heroku isn’t your specific gripe here, but I think it’s important that we focus on providing guidance and a secure path for teams and platforms that are doing the right thing.
> 
> -cmort
> 
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 02 Jun 2011 10:54:18 +0200

I agree with Skylar. In the end, the most important point is how much 
the authorization server trusts the particular client and what 
privileges are associated with that client identity. In an open 
development model, I would not trust the client in the least and instead 
require the user to authorize access. Authenticity and trustworthiness 
of apps in general is not the task of an OAuth authorization server.

I would put it the other way around. If a client wants/is supposed to 
have privileged access to resources (without or with less need for 
additional user authorization), it must be able authenticate itself in a 
reliable way.

regards,
Torsten.

Am 02.06.2011 01:20, schrieb Skylar Woodward:
>> On 6/1/11 12:17 PM, "Skylar Woodward"<[email-masked]>  wrote:
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 02 Jun 2011 10:59:54 +0200

Dave, Skylar,

the assumption of the OAuth 2.0 security threat model 
(http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1) 
is that client secrets, which are distributed with applications, cannot 
reliably kept confidential. Therefore the advice is given to use other 
means to validate the client identity (e.g. user consent, platform 
security measures).

I would highly appreciate if you would review this document and give us 
feedback.

thanks in advance,
Torsten.

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 2 Jun 2011 15:17:04 -0400

Hi Torsten, folks,

I reviewed the text of Section 4.1 of draft-lodderstedt-oauth-security, and also the text of Section 9 of oath-draft16.

I think there seems to be a disconnect (may be its just me).

(a) Oauth2.0 today is designed for low-assurance environments. So I think the WG is wasting a lot of time in trying to address whether the Client can keep secrets. The WG should just assume that the problem of keeping secrets is out of scope for Oauth. Unless we are trying to address high-assurance environments (and start talking about smartcards, HSMs, TPMs, trusted execution, trusted boot, etc), I think the WG should just move on. 

ps. Section 4.1 is OK, but this WG will not be able to solve many of the problems listed in Section 4.1

(b) The current text of Section 9 says:

]]]] Native applications SHOULD use the authorization code 
]]]] grant type flow without client password credentials (due to their
]]]] inability to keep the credentials confidential) to obtain
]]]] short-lived access tokens, and use refresh tokens to maintain access.

When it comes to "keeping secrets" I don't know why we are assuming that a native application (software running in user-space managed by an OS) is any worse than a browser (user-agent). Did I misunderstood the definition of a native application?

Thanks.

/thomas/

_________________________________

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Torsten Lodderstedt
> Sent: Thursday, June 02, 2011 5:00 AM
> To: Skylar Woodward
> Cc: [email-masked]
> >> sufficiently obfuscated in code delivered in binary format without
> >> the benefit of a symbol table, so as to be sufficiently resistant to
> > I have empirical evidence to support this. At Yahoo! we devised one
> of the most complex systems I've ever seen in a publicly distributed
> program (Messenger). It was disassembled in 3 days. Scott Renfro (now
> over with David at Facebook) and likely Bill Mills can also vouch for
> the difficulty of this having also studied the case well.
> >
> > Moreover if a hardware-enforced system like that of Playstation 3 can
> be broken, then so can most systems. The PS3 protection mechanisms
> are/were very sophisticated.
> >
> > Even if a system is not yet cracked or is very hard, you have to
> assume it can be cracked. History has shown this to be true nearly
> without exception - at least to the point it is not worth considering
> for the OAuth use cases.
> >
> > skylar
> >

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 02 Jun 2011 15:43:56 -0400

Thomas Hardjono wrote:
>
> (a) Oauth2.0 today is designed for low-assurance environments.
I don't think that was an objective.  At least, the charter does not say 
that...
>  So I think the WG is wasting a lot of time in trying to address whether the Client can keep secrets. The WG should just assume that the problem of keeping secrets is out of scope for Oauth. Unless we are trying to address high-assurance environments (and start talking about smartcards, HSMs, TPMs, trusted execution, trusted boot, etc), I think the WG should just move on. 
>   
Yes, but the objective here was to document *considerations*, which I 
think the document has done very well.  (By the way, personally I would 
very much like to address high-assurance environments, but I respect the 
consensus on getting 2.0 finished before this is addressed. All the 
more, it is important to point out the potential weaknesses in the 
security considerations section.)
> ps. Section 4.1 is OK, but this WG will not be able to solve many of the problems listed in Section 4.1
I have a different opinion on that, which is much more optimistic.  But, 
again, the objective of considerations is posing the problems, and this 
is done very well, in my opinion.
> When it comes to "keeping secrets" I don't know why we are assuming that a native application (software running in user-space managed by an OS) is any worse than a browser (user-agent). Did I misun…

Maybe I misunderstood something, but I think that native applications 
rely on OS for keeping secrets.

Igor

---

From: Brian Eaton <[email-masked]>
Date: Thu, 2 Jun 2011 12:51:29 -0700

On Thu, Jun 2, 2011 at 12:17 PM, Thomas Hardjono <[email-masked]> wrote:

> (a) Oauth2.0 today is designed for low-assurance environments. So I think
> the WG is wasting a lot of time in trying to address whether the Client can
> keep secrets. The WG should just assume that the problem of keeping secrets
> is out of scope for Oauth. Unless we are trying to address high-assurance
> environments (and start talking about smartcards, HSMs, TPMs, trusted
> execution, trusted boot, etc), I think the WG should just move on.
>

In terms of support for things like HSMs, check out this web site:

https://sites.google.com/site/oauthgoog/authenticate-google-app-engine-app

I agree with you that the working group should probably move on from the
topic of keeping secrets in native apps, because what we say on this topic
is not going to change industry practice at all.

But it is important that the protocol support higher security environments
where secrets really are secrets.  That's an area where protocol changes do
have impact on industry practice, and we should be careful not to screw it
up.

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 2 Jun 2011 14:31:10 -0700 (PDT)

In theory this is true..

> I firmly believe that secrets can be sufficiently obfuscated 

> in code delivered in binary format without the benefit of a 

> symbol table, so as to be sufficiently resistant todiscovery 

> via disassembly by attackers you'd expect to encounter in a

> typical commercial environment.

In practice there are an extremely small number of cases where this is actually done right, and legions of cases where it's done wrong.  Industry just doesn't get this right often enough to rely on it.

-bill

________________________________
From: Dave Nelson <[email-masked]>
To: Skylar Woodward <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Wednesday, June 1, 2011 12:43 PM
Subject: Re: [OAUTH-WG] Text for Native Applications

Agreed.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 2 Jun 2011 14:33:38 -0700 (PDT)

I wish I could talk about it.  You'll have to find someone who's not bound by stuff like employment contracts and trades secrets stuff to tell you the story.

________________________________
From: Skylar Woodward <[email-masked]>
To: Dave Nelson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Wednesday, June 1, 2011 1:07 PM
Subject: Re: [OAUTH-WG] Text for Native Applications

skylar

---

From: Brian Eaton <[email-masked]>
Date: Thu, 2 Jun 2011 14:40:18 -0700

On Thu, Jun 2, 2011 at 2:31 PM, William J. Mills <[email-masked]>wrote:

> In practice there are an extremely small number of cases where this is
> actually done right, and legions of cases where it's done wrong.  Industry
> just doesn't get this right often enough to rely on it.
>

Well, "rely" is a strong-term.  I know of various teams who do this.  I
don't know of any teams that put a heavy reliance on it.

---

From: Dave Nelson <[email-masked]>
Date: Thu, 2 Jun 2011 17:54:42 -0400

> don't know of any teams that put a heavy reliance on it.

It might validly be just one element of a defense-in-depth strategy.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Shane B Weeden <[email-masked]>
Date: Fri, 3 Jun 2011 16:05:16 +1000

Would anyone care to explain what the value of a refresh token is for peer
to peer applications utilizing the client_credentials grant type,  or
validate if my explanation is the intended use case?

Recall:
* it is required to provide client credentials to get an access token [and
refresh token]
* it is also required to provide client credentials to exchange a refresh
token for an access token (small assumption here based on recent
discussions ... but I think it had better be for the client_credentials
flow)
* unlike the authorization code flow, there is no authorization step with
the user involved that makes obtaining a new access token directly from the
client credentials any less onerous than using a refresh token

About the only use case I can contrive that makes any sense is when
multiple instances of apps use the same client credentials (already a bad
idea) and you want to revoke access to a subset of them. To do the
revocation you would need to simultaneously:
1. Revoke the refresh token and any access tokens issued to compromised
instances
2. Update the client secret (or whatever authentication method clients
have) on those client instances that are still considered ok.

In a deployment where each client has it's own credentials, which should be
"situation normal" from a security perspective, I don't see any value for
the refresh token. I also cringe at the idea of someone suggesting that
refresh token can be presented without client credentials - in this case
that's like saying client X has n passwords, where n is the number of
issued refresh tokens. Better to create n sets of client credentials in the
first place.

Thanks,
Shane.

---

From: Skylar Woodward <[email-masked]>
Date: Fri, 3 Jun 2011 10:46:13 +0200

This may be true for a "secret" of sorts in some applications, but not for the client_credential in OAuth. The client secret is the only element that can secure the identity of the app and if it is compromised then so is the ability of the app to assert its identity. There's no way a software program on a open mass-market runtime can secure the secret as a part of its own software distribution (and likely true for any mass-distirbuted system) . So we should stick with the advisement that apps that can't keep secrets not be issued them - its a big win for setting the correct expectations to developers and users over 1.0.

If the client_secret were merely one element in protecting access maybe this your suggestion would be true. However, given the difficulty of embedding and obfuscating a secret in a hard-to-find way, and the requirement that every developer would have to do this in his own proprietary and secret way, it seems not a scalable solution for the multitudes of apps that will be OAuth clients. It's better for developers to consider other mechanisms - starting with secure distribution of the software.

skylar

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 03 Jun 2011 10:58:36 +0200

+1

Skylar Woodward <[email-masked]> schrieb:

skylar

> It might validly be just one element of a defense-in-depth strategy.

_____________________________________________

OAuth mailing list
[email-masked]

---

From: "William J. Mills" <[email-masked]>
Date: Fri, 3 Jun 2011 08:02:36 -0700 (PDT)

+1

________________________________
From: Torsten Lodderstedt <[email-masked]>
To: Skylar Woodward <[email-masked]>; Dave Nelson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Friday, June 3, 2011 1:58 AM
Subject: Re: [OAUTH-WG] Text for Native Applications

+1

>
>If the client_secret were merely one element in protecting access maybe this your suggestion would be true. However, given the difficulty of embedding and obfuscating a secret in a hard-to-find way, and the requirement that every developer would have to do this in his 
 own
proprietary and secret way, it seems not a scalable solution for the multitudes of apps that will be OAuth clients. It's better for developers to consider other mechanisms - starting with secure distribution of the software.

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 3 Jun 2011 09:45:26 -0700

> validate if my explanation is the intended use case?

Are you asking why would an authorization server issue a refresh token
when the client credentials grant type is used?

My guess is that in most cases authorization servers will not issue a
refresh token in this case. Refresh tokens are optional, see sections
4.4.3 and 5.1.

I think that the example in 4.4.3 should show only an access token.
Also, section 4.4.3 should probably state that in this case the
authorization server SHOULD not issue a refresh token.

Section numbers are for draft 16.

Marius

---

From: Brian Eaton <[email-masked]>
Date: Fri, 3 Jun 2011 10:09:32 -0700

Agreed, it's nuts to return a refresh token for that flow.

Eran, why is this still in the spec?  You agreed to remove it almost a
year ago.  It's come up multiple times since then.

http://www.ietf.org/mail-archive/web/oauth/current/msg03651.html

Cheers,
Brian

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 17 Jun 2011 07:27:54 +0200

Hi Thomas,

> When it comes to "keeping secrets" I don't know why we are assuming that a native application (software running in user-space managed by an OS) is any worse than a browser (user-agent). Did I misun…

I would assume "a browser" refers to apps running within the browser. 
http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10 calls them 
user-agent-based apps. For both user-agent-based and native apps, the 
text states the assumption that "The OAuth protocol data and credentials 
are accessible to the end-user.". So both are equivalent with respect to 
the topic discused in this thread. For native apps, another important 
issue is the way their client secret (today) is typically assigned and 
distributed (backed into the binary). So the same secret is accessible 
in all installations. This is considered bad practice by many people.

Web applications are quite different since the OAuth credentials are 
kept in a server under control of the service provider and not 
accessible to the end-user.

regards,
Torsten.