Do you really need to secure your application credentials?

If you write an app, you need that app to have a way to GET/POST/PUT/DELETE objects, you need credentials. And you need to keep those credentials secure.

Or do you?

I’m talking about web apps here. Things like standalone JavaScript that you can run locally in a browser without all that pesky server-side code. These apps have to carry their credentials around with them, and even if the creds are buried deep in a configuration file or in a script, someone, or something, is going to be able to read your app credentials.

And again, is that really a problem?

It’s only a problem if those credentials can do anything that you couldn’t do publicly anyhow. The real GET/POST/PUT/DELETE power lies with the user credentials, not the application credentials. And even then, that user should only be able to GET/POST/PUT/DELETE things that particular user is allowed to GET/POST/PUT/DELETE.

The client credentials should really only be able to do one thing.

Authorization Grant: Use a code provided by the API identity service that a user generated

It might need to facilitate setting up an initial user, but possibly not even that if we rely entirely on codes from users.

The client credentials assigned to an app are used pretty much as a way to know which app the consumer is using. It lets you turn off those keys if you feel like someone is abusing the authority, but if your user credentials only let the app interact with that one users info then the exposure is fairly limited.

Now I'm not saying you should publish your keys willy-nilly, but I am saying that if there is any possibility of the keys being exposed, then you should design security as if it's already in the wrong hands by limiting what the app can do on its own, and limit what individual users can do when they log in.

Here's a quick review of how the Authorization Grant flow works…