Ask HN: What kind of authentication model do you use for your API service?
Ok, so I am building yet another API.
This time I wanted to go through some types of authentication implementations to see which one would be simplest for our customers to implement, and which one would be more secure.
How do you let your API users authenticate?
* Creating "Apps" in your service?
* User based Private/Public key?
* Username/Password
* oAuth?
Other ideas?
-- EDIT: Updated linebreaks in list.
Comments
Some resources if anyone is interested to read:
http://blog.apigee.com/detail/do_you_need_api_keys_api_ident...
In short: http://stackoverflow.com/questions/6767813/api-keys-vs-http-...
I would love more insights though - from real implementations! :)
I create mobile apps against a REST backend on GAE and I use just basic authentication over https for authenticating the users. I sha1 the password and compare against a sha1 value in the database. Simplest there is but maybe not as secure as other alternatives, but I have not found any big problems with this. Please tell me if I am missing something vital. Have bought a book about OAuth but have not opened it yet. :)
Read: http://codahale.com/how-to-safely-store-a-password/
Since you're running on GAE you're likely using either python or java:
Python bcrypt implementation: http://www.mindrot.org/projects/py-bcrypt/
Java bcrypt implementation: http://www.mindrot.org/projects/jBCrypt/
I was aiming more for app <-> app authentications more than app <-> user authentication, but in your case I would definitely use at least a salt for your sha1 hashed passwords.
oAuth seems to have quite a large pool of samples and classes here which I found useful; http://oauth.net/code/
Have you considered 2 factor authentication? If you are concerned about security 2FA can give you more protection- - Maruf
Hey kuasha!
That sounds interesting, how would you implement that on an API level in a good way? I mean, the clients applications will most probably do automatic transactions all the time.
Are you thinking something like time-based sessions, which you have to authenticate on both ends - with a PK?
2FA can use smart card- The device with TPM capability may work as a virtual smart card- This video is interesting- http://www.youtube.com/watch?v=QmTpdZAC4_s -
But Yes, I have to admit, for API, this may be overkill-
So you would implement like a virtual smart-card in the Client application end that then communicates with the API in our end and authenticates?
I also think this might be a bit overkill - maybe something for real enterprise apps... :-)
But it's a cool thought!
Thanks for sharing!
oAuth, preferred for it's simplicity.
I guess you are referring to version 1 of oAuth?
Seems like there is a lot of talk regarding the 2nd generation of oAuth.
Do you have any insight to share regarding that?