Hacker News new | past | comments | ask | show | jobs | submit login

Author here. I wrote a simpler blog that summarizes the spreadsheet - https://hashedin.com/2016/07/05/choosing-right-authenticatio.... It may help you to find an approach that meets your needs



Thanks for making and sharing this document. I need to choose an authentication method for our distributed application.

I'm confused by the type of usage covered. Are these for web sites accessed by browsers (users), or clients (e.g. swagger) accessing micro service REST API servers ?

Support of cookies is built in browsers, but what about authentication with clients ? It looks like JWT is the most versatile and supported in many languages. But it's still unclear how I'm supposed to use them.

Where could I find more about this ?


For clients outside of the browser, you have a few choices. JWT token passed in authorization header, or a secure random token passed in authorization header, or a signature that verifies the client has access to a secret.

The easiest way is to create a secure random token and store it in database or in-memory cache like Redis. When a request comes in, you extract the token and check your database/cache if the token is valid. The drawback is an additional network call to the database/cache every API call. If your application can afford this extra call, this is a pretty good approach.

With JWT, you don't have to make an extra network call, because the token itself has everything you need to verify if it's valid. But, if you want the ability to revoke the token - then you will need to maintain a blacklist of tokens somewhere, and check against this blacklist on every request. Arguably, at that point, you lose the original benefit of JWT - the ability to bypass the database/cache.

And finally, if your clients are server side applications only, then you can opt in for signature based approaches.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: