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:
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:
$ 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"<sky...@kiva.org> wrote:
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 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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
