Best way to handle user authentication across website and gem client

Question

We are working on a service that will have website access for stats and other tasks, but the majority of use will be through a client gem and rake tasks. What is the best way to handle authentication for both pieces.

It looks like fiveruns_tuneup, getexceptional, New Relic and others have websites with username and pass, but use API keys stored in ./config/serviceName.yml Any reasons it is better to have API keys opposed to user/pass in the config (do they use keys because often the key is checked into SCM and used across the project, where ours would not be checked in and would be a per user setting)

GitHub has you put your public key on the github servers and uses that, but I think git supports public/private key by default.

Would it be preferred to keep a ./config/serviceName.yml or since we have to create a subdirectory with other information have ./serviceName/config.yml? (does the per user, not stored in SCM mean it is better to keep it all in one excluded directory?)

Just looking for some thoughts and ideas on best practices before starting implementation.

Answer 1

The github approach is bootstrapping on top of existing git practices, however it's not a bad idea since presumably each user will have their own private key to match a published public one in the central authority. Since key-agent's already furnish a means of safe authentication this seems like a very safe approach. Public/private keys are a well thought out authentication scheme, which has unfortunately been reinvented many times to limited success.

The problem with the API key is that anyone who gets a copy of the API key can do whatever that authorizes. Storing the API key somewhere in the project begs the users to share a key. If you are associating public keys with a user, it is possible to grant rights to the client on a per user basis, and a proper key-agent approach suggests that those will not be stored in an SCM anywhere.

I'm not sure I follow what the distinction between config/serviceName.yml, or serviceName/config.yml is. It doesn't seem as if it would be pertinent if you have public/private keys as an authentication method for the client.

Answer 2

I recommend that you use username/password combos for website accounts, and API keys for any web services. Here are the advantages of this technique:

1. By linking API keys to an account, you could have many API keys for the same user. Perhaps this could be used for many remote web servers that consume this data service, or to perform unique tracking.
2. Attaching API keys to an account also lets you keep the user's username and password uncompromised since an API key will not contain them. Many users use the same username and password on many services, so you are helping to protect them.
3. You could limit access to portions of functionality for each API key, but give their username access to everything their account should have access to. Additionally, you can even give them the ability to limit how much access an API key might have.

Most of the major services (Yahoo! API, Flickr, Google API, etc) use accounts with a username and password to login to the web account, and API keys for integration points.

Answer 3

Never use user/pass when you can help it. The security issues are horrible. If the user/pass leaks out, you have to change your password or they get access to your whole account.

API keys are better because they're easier to change and can be limited to only the part you need access to with the APIs (ie, if someone has your password they can change your password. They can't if they just have an API key).

Different API key per client or secure token exchange (such as OAuth) is the best solution if you'll have more than just your client on the API.