REST API Authentication

Question

I m building an application which will be hosted on a server  I want to build an API for the application to facilitate interaction with from any platform  Web App  Mobile App   What I m not understanding is that when using the REST API  how do we authenticate the user   For example  when a user has logged in and then wants to create a forum topic  How will I know that the user is already logged in

User · Accepted Answer

You can use HTTP Basic or Digest Authentication. You can securely authenticate users using SSL on the top of it, however, it slows down the API a little bit.

Basic authentication - uses Base64 encoding on username and password
Digest authentication - hashes the username and password before sending them over the network.

OAuth is the best it can get. The advantages oAuth gives is a revokable or expirable token. Refer following on how to implement: Working Link from comments: https://www.ida.liu.se/~TDP024/labs/hmacarticle.pdf

User · Answer

Use HTTP Basic Auth to authenticate clients  but treat username password only as temporary session token   The session token is just a header attached to every HTTP request  eg  Authorization  Basic Ym9ic2Vzc2lvbjE6czNjcmV0  The string Ym9ic2Vzc2lvbjE6czNjcmV0 above is just the string  bobsession1 s3cret   which is a username password  encoded in Base64  To obtain the temporary session token above  provide an API function  eg  http   mycompany com apiv1 login  which takes master-username and master-password as an input  creates a temporary HTTP Basic Auth username   password on the server side  and returns the token  eg  Ym9ic2Vzc2lvbjE6czNjcmV0   This username   password should be temporary  it should expire after 20min or so  For added security ensure your REST service are served over HTTPS so that information are not transferred plaintext   If you re on Java  Spring Security library provides good support to implement above method

User · Answer

Here s a guided approach  Your authentication service  issues a JWT token that is signed using a secret that is also available in your API service  The reason they need to be there too is that you will need to verify the tokens received to make sure you created them  The nice thing about JWTs is that their payload can hold claims as to what the user is authorised to access should different users have different access control levels  That architecture renders authentication stateless  No need to store any tokens in a database unless you would like to handle token blacklisting  think banning users   Being stateless is crucial if you ever need to scale  That also frees up your API service from having to call the authentication server at all as the information they need for both authentication and authorisation are in the issued token  Flow  no refresh tokens    User authenticates with the authentication server  eg  POST  auth login  and receives a JWT token generated and signed by the auth server  User uses that token to talk to your API and assuming user is authorised   gets and posts the necessary resources   There are a couple of issues here  Namely  that auth token in the wrong hands provides unlimited access to a malicious user to pretend they are the affected user and call your APIs indefinitely  To handle that  tokens have an expiry date and clients are forced to request new tokens whenever expiry happens  That expiry is part of the token s payload  But if tokens are short-lived  do we require users to authenticate with their usernames and password every time  No  We do not want to ask a user for their password every 30min to an hour  and we do not want to persist that password anywhere in the client  To get around that issue  we introduce the concept of refresh tokens  They are longer lived tokens that serve one purpose  act as a user s password  authenticate them to get a new token  Downside is that with this architecture your authentication server needs to persist these refresh token in a database  New flow  with refresh tokens    User authenticates with the authentication server  eg  POST  auth login  and receives a JWT token generated and signed by the auth server  alongside a long lived  eg  6 months  refresh token that they store securely Whenever the user needs to make an API request  the token s expiry is checked  Assuming it has not yet expired  user uses that token to talk to your API and assuming user is authorised   gets and posts the necessary resources  If the token has indeed expired  there is a need to refresh your token  user calls authentication server  EG  POST   auth token  and passes the securely stored refresh token  Response is a new access token issued  Use that new token to talk to your API image servers   OPTIONAL  banning users  How do we ban users  Using that model there is no easy way to do so  Enhancement  Every persisted refresh token includes a blacklisted field and only issue new tokens if the refresh token isn t black listed  Things to consider   You may want to rotate refresh token  To do so  blacklist the refresh token each time your user needs a new access token  That way refresh tokens can only be used once  Downside you will end up with a lot more refresh tokens but that can easily be solved with a job that clears blacklisted refresh tokens  eg  once a day  You may want to consider setting a maximum number of allowed refresh tokens issued per user  say 10 or 20  as you issue a new one every time they login  with username and password   This number depends on your flow  how many clients a user may use  web  mobile  etc  and other factors  Logout endpoint in your authentication service may or may not blacklist refresh tokens  Something to think about

User · Answer

For e g  when a user has login Now lets say the user want to create a forum topic  How will I know that the user is already logged in   Think about it - there must be some handshake that tells your  Create Forum  API that this current request is from an authenticated user  Since REST APIs are typically stateless  the state must be persisted somewhere  Your client consuming the REST APIs is responsible for maintaining that state  Usually  it is in the form of some token that gets passed around since the time the user was logged in  If the token is good  your request is good    Check how Amazon AWS does authentications  That s a perfect example of  passing the buck  around from one API to another     I thought of adding some practical response to my previous answer  Try Apache Shiro  or any authentication authorization library   Bottom line  try and avoid custom coding  Once you have integrated your favorite library  I use Apache Shiro  btw  you can then do the following    Create a Login logout API like   api v1 login and api v1 logout In these Login and Logout APIs  perform the authentication with your user store The outcome is a token  usually  JSESSIONID  that is sent back to the client  web  mobile  whatever  From this point onwards  all subsequent calls made by your client will include this token Let s say your next call is made to an API called  api v1 findUser The first thing this API code will do is to check for the token   is this user authenticated    If the answer comes back as NO  then you throw a HTTP 401 Status back at the client  Let them handle it  If the answer is YES  then proceed to return the requested User   That s all  Hope this helps

User · Answer

I ve been using the JWT authentication  Works just fine in my application   There is an authentication method that will require the user credentials  This method validates the credentials and returns an access token in case of success   This token must be sent to every other method in my Web API in the header of the request   It s pretty easy to implement  and very easy to test

User · Answer

I think the best approach is to use OAuth2  Google it and you will find a lot of useful posts to help you set it up   It will make easier to develop client applications for your API from a web app or a mobile one   Hope it helps you

[api] REST API Authentication

Examples related to api

Examples related to rest