Behalf
Of Torsten Lodderstedt
Sent: Thursday, June 02, 2011 5:00 AM
To: Skylar Woodward
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Text for Native Applications
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
+1
From: Torsten Lodderstedt
To: Skylar Woodward ; Dave Nelson
Cc: "oauth@ietf.org"
Sent: Friday, June 3, 2011 1:58 AM
Subject: Re: [OAUTH-WG] Text for Native Applications
+1
Skylar Woodward schrieb:
This may be true for a "secret&qu
+1
Skylar Woodward schrieb:
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 ident
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 pr
On Thu, Jun 2, 2011 at 5:40 PM, Brian Eaton wrote:
> 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.
It might validly be just one element of a defense-in-depth strategy.
Regards,
Dave
David B. Nelson
Sr. Softwa
On Thu, Jun 2, 2011 at 2:31 PM, William J. Mills 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.
June 1, 2011 1:07 PM
Subject: Re: [OAUTH-WG] Text for Native Applications
On Jun 1, 2011, at 9:43 PM, Dave Nelson wrote:
> 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
From: Dave Nelson
To: Skylar Woodward
Cc: "oauth@ietf.org"
Sent: Wednesday, June 1, 2011 12:43 PM
Subject: Re: [OAUTH-WG] Text for Native Applications
> The group is operating under the assumption that most
> native apps are publicly deployed or that copies of the
> app bund
On Thu, Jun 2, 2011 at 12:17 PM, Thomas Hardjono 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
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 assum
; Of Torsten Lodderstedt
> Sent: Thursday, June 02, 2011 5:00 AM
> To: Skylar Woodward
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Text for Native Applications
>
> Dave, Skylar,
>
> the assumption of the OAuth 2.0 security threat model
> (http://tools.ietf.org/html
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
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 autho
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 sustaine
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
On Jun 1, 2011, at 9:43 PM, Dave Nelson wrote:
> 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
> 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 pos
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
On Jun 1, 2011, at 6:54 PM, Brian Eaton wrote:
>> (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?
Simple really, I just mean for some developers it might be more important to
have an open development
> 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
On Wed, Jun 1, 2011 at 1:41 AM, Skylar Woodward wrote:
> 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
On Wed, Jun 1, 2011 at 9:11 AM, William J. Mills wrote:
>> - 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.
Sorry, didn't mean to suggest that password grants would go away. The
business need is clear
011 1:18 AM
Subject: Re: [OAUTH-WG] Text for Native Applications
On Wed, Jun 1, 2011 at 12:47 AM, Torsten Lodderstedt
wrote:
>> - ignore the problem and leave the spec vague and insecure.
>
> Could you please describe what you consider "insecure"?
As an example, optional cl
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 (Fo
On Jun 1, 2011, at 10:18 AM, Brian Eaton wrote:
> 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.
I just want to re-iterate my point from a few months ago that it necessarily
helpful to draw the li
> 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".
+1. stop muddying the waters
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
On Wed, Jun 1, 2011 at 12:47 AM, Torsten Lodderstedt
wrote:
>> - ignore the problem and leave the spec vague and insecure.
>
> 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 s
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 unspeci
Am 01.06.2011 08:56, schrieb Brian Eaton:
On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore
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
On 6/1/11 12:20 AM, "Brian Eaton" wrote:
On Wed, Jun 1, 2011 at 12:15 AM, Torsten Lodderstedt
wrote:
> I'm getting confused. This thread is about native apps. So why discuss
> security considerations for web apps here?
They overlap because they both use refresh tokens. =/ When people
propos
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
On Wed, Jun 1, 2011 at 12:15 AM, Torsten Lodderstedt
wrote:
> I'm getting confused. This thread is about native apps. So why discuss
> security considerations for web apps here?
They overlap because they both use refresh tokens. =/ When people
propose changes that impact refresh tokens, it impac
On Wed, Jun 1, 2011 at 12:08 AM, Chuck Mortimore
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
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 wrote:
If a provider chooses to do that though, in the attack you descri
On 5/31/11 11:56 PM, "Brian Eaton" wrote:
On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore
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 agr
On Tue, May 31, 2011 at 11:47 PM, Kris Selden 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,
> all
On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore
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
Yes, it is important to remember that when you make allowances for one flow you
affect other flows, I understand that. I understand that if in the implicit
flow you return a refresh token, you then allow other flows to use
authorization server endpoint to refresh the token without a client secr
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 chanc
-Doug Tangren
http://lessis.me
For example, a iOS app that is shipped through iTunes certainly has access
> to reasonably secure storage via KeyChain for secrets issued to the
> application at runtime, such as the referesh_token, but it can’t do a good
> job of protecting the client_secret, since
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 cr
-Doug Tangren
http://lessis.me
On Wed, Jun 1, 2011 at 1:39 AM, Kris Selden wrote:
> Why can't you just revoke the refresh token for a client when you change
> the client secret?
>
>
This makes sense for a server implementation for added precaution but in
practice, most clients dont change clien
The distinction is that the client_secret tends to be a global secret, and
there is little ability to protect this type of secret in many common means of
application distribution.
For example, a iOS app that is shipped through iTunes certainly has access to
reasonably secure storage via KeyChai
On Tue, May 31, 2011 at 10:39 PM, Kris Selden wrote:
> Why can't you just revoke the refresh token for a client when you change the
> client secret?
>
> Is it not easier to revoke a token than it is to rotate the client secret
> (which is usually configured or embedded in the client whereas the
Why can't you just revoke the refresh token for a client when you change the
client secret?
Is it not easier to revoke a token than it is to rotate the client secret
(which is usually configured or embedded in the client whereas the token is
issued)?
On May 31, 2011, at 5:37 PM, Brian Eaton wr
>
>
>
> Consider what happens when a client web server is compromised and the
> client secret and refresh tokens are stolen.
> - the attacker can use the tokens until the compromise is discovered.
> - the client secret is then changed
> - the stolen refresh tokens then become useless
>
> Now, *if*
On Tue, May 31, 2011 at 10:41 AM, Chuck Mortimore
wrote:
> Updated in language I just sent out – thanks.
>
> On that note, we currently return refresh_token using the implicit grant
> type under certain controlled circumstances. Facebook in turn uses the
> implicit grant type, and simply issues
This issue has likely been discussed "long ago", but I'd like to
potentially re-open the discussion.
> o Native applications that use the authorization code grant type flow
> SHOULD do so without client password credentials, due to their inability to
> keep those credentials confidential.
I u
Am 31.05.2011 20:00, schrieb Doug Tangren:
-Doug Tangren
http://lessis.me
On Tue, May 31, 2011 at 1:41 PM, Chuck Mortimore
mailto:cmortim...@salesforce.com>> wrote:
Updated in language I just sent out – thanks.
On that note, we currently return refresh_token using the implicit
the security considerations section does recommend to not automatically
process repeated authorizations without validating the client's identity
The authorization server SHOULD NOT automatically, without active
end-user interaction, process repeated authorization requests without
authentic
Date: Tue, 24 May 2011 17:30:05
To: oauth@ietf.org@ietf.org>
Subject: [OAUTH-WG] Text for Native Applications
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_
On Tue, May 31, 2011 at 12:00 PM, Doug Tangren wrote:
>
> I think there is still a usability issue with the implicit flow in general
> where there is no way in the spec to obtain an access token without
> re-asking the user for authorization a second time even if the user has
> already authorized
-Doug Tangren
http://lessis.me
On Tue, May 31, 2011 at 1:41 PM, Chuck Mortimore
wrote:
> Updated in language I just sent out – thanks.
>
> On that note, we currently return refresh_token using the implicit grant
> type under certain controlled circumstances. Facebook in turn uses the
> implic
his in the comparision with the implicit grant type.
regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland
-Original Message-
From: Chuck Mortimore
Sender: oauth-boun...@ietf.org
Date: Tue, 24 May 2011 17:30:05
To: oauth@ietf.org
Subject: [OAUTH-WG] Text for Native Ap
Sender: oauth-boun...@ietf.org
Date: Tue, 24 May 2011 17:30:05
To: oauth@ietf.org
Subject: [OAUTH-WG] Text for Native Applications
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
One of my items from yesterday was to update the text related to native
applications. Primary goals were to:
1. remove the explicit preference for authorization_code grant type
2. provide a brief overview on means of initiating authorization requests and
receiving callbacks
3. discuss t
56 matches
Mail list logo
