Ask HN: What is the best way to add authentication to REST API (for mobile)?
Newbie Question: What is a secure and accepted way for authentication and authorisation of REST API endpoint for mobile and SPA's? A google search usually yields JWT but from what I know about JWT, it's complex and doesn't support revocation of tokens easily. There are pros and cons of JWT but if you are OK with it, it is not complex if you use a library. JWT purists want everything on the token (no database) but if you are OK with using a database, just store the token and delete it to revoke. When authenticating, add a database query (it's not that bad) in addition to the verification of the token If you're using AWS, maybe take a look at Cognito? https://docs.aws.amazon.com/cognito/latest/developerguide/wh... If you control both the backend and the front end, just use a session cookie. The humble session cookie is what I've been using all these years, but now suddenly everyone is saying "JWT". Any advice on the pros and cons of JWT vs session cookies? JWT is a buzzword. Some people are attracted to changing shit for the sake of it, and then encouraging others to use the new thing too, to validate their own use, and feel like they're 'ahead of the curve' on trendy tech. Rather than rehashing it all myself, I'd suggest reading http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo... and https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-... No real difference IMHO, JWT just introduces some "standards" for some interoperability. Session cookies could be anything Auth0 is not a bad option. For JWT to support revocation, you must store them in the database and delete them on logout or when they expire. To clarify for JWT invalidation, you don’t have to store the whole token. Instead just store the jti or some other identifying field that can be checked. Can you please elaborate on this? The JWT specification defines a payload attribute named jti which is used to store the token's nonce/id. To avoid replay attacks, the backend adds the token's nonce to a scratchpad memory when the token is used in order to invalidate the token even if the expiration timestamp isn't reached. If a JWT implementation is implemented to ignore replay attacks or even token expiration, the jti can still be used to invalidate tokens. May be you are interested in this page
https://sushi2k.gitbooks.io/the-owasp-mobile-security-testin... JWT is not that complex because there are battle tested libraries available for all languages. I agree, and I was thinking of using go-jwt but given the bad rap it has received here https://news.ycombinator.com/item?id=13865459 and here https://news.ycombinator.com/item?id=17877332, I'm having second thoughts as I don't want to mess things up. Also, I don't really need a stateless token just something that will allow for authentication from my server, Google OAuth and Facebook OAuth. Use a session cookie. An API Gateway is pretty Quick to set up, but the industry is moving away from it as a concept. Keycloak is nice but requires some work. > An API Gateway is pretty Quick to set up, but the industry is moving away from it as a concept. Can you elaborate on this? Seconded - I’d like to hear more behind your reasoning. Third - I'm in the 'industry' and would like to understand that more. Depends on your requirements... Quick and easy: Look into Firebase. Powerful/extensible: Django + DRF I would prefer a scalable solution. Go with PostgreSQL is my current stack. huh? Sorry wrong wording there. I'm currently using Golang (so, no DRF) and I don't want to use Firebase. My question was if I just stored the session tokens in the Postgres DB, will it take a performance hit, or should I store them in an in-memory store like Redis or Memcached?