[tptacek]

OAuth is overkill for what you're working on. You generally won't go wrong with the rule of thumb that you do the least amount of cryptography your design requires you to. You should be dragged kicking and screaming into more of it. In this case, generating a long random token and using that to authorize requests has all the basic security benefits of an OAuth bearer token and almost none of the attack surface. Long random tokens are the most overrated technology in authentication.

A general rule of thumb w/r/t/ OAuth is that it starts to make sense when you are delegating authorization to other companies that share your users. Think "TweetLater".

[cpach]

“Long random tokens are the most overrated technology in authentication.”

Just so I follow, did you mean underrated…?

[tptacek]

Yeah, sorry!

[laurent92]

But then you need to implement token revocation, by the host, the user or the client, and find a cryptographically-secure way to generate the key.

[wolf550e]

To revoke the token, the server deletes it from the database. If you have the token, you can ask the server to delete it from the database. The cryptographically secure way to generate it is to read 32 bytes from getrandom(2) or from /dev/urandom.

[merb]

you basically told somebody to roll his own crypto. that is a stupid idea. using refresh tokens and access tokens in a standard way is way more secure than rolling your own, this stuff is already pretty hard. of course one could go with a simple cookie login, but when it comes to external apps, that's not always a good idea, especially not if you need to revoke specific applications.

so your general rule of thumb is pretty stupid.

[wglb]

In what way is getting 32 bytes from /dev/urandom rolling your own crypto?