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
