RESTful Authentication

Question

What does RESTful Authentication mean and how does it work   I can t find a good overview on Google   My only understanding is that you pass the session key  remeberal  in the URL  but this could be horribly wrong

User · Answer

To answer this question from my understanding...

An authentication system that uses REST so that you do not need to actually track or manage the users in your system. This is done by using the HTTP methods POST, GET, PUT, DELETE. We take these 4 methods and think of them in terms of database interaction as CREATE, READ, UPDATE, DELETE (but on the web we use POST and GET because that is what anchor tags support currently). So treating POST and GET as our CREATE/READ/UPDATE/DELETE (CRUD) then we can design routes in our web application that will be able to deduce what action of CRUD we are achieving.

For example, in a Ruby on Rails application we can build our web app such that if a user who is logged in visits http://store.com/account/logout then the GET of that page can viewed as the user attempting to logout. In our rails controller we would build an action in that logs the user out and sends them back to the home page.

A GET on the login page would yield a form. a POST on the login page would be viewed as a login attempt and take the POST data and use it to login.

To me, it is a practice of using HTTP methods mapped to their database meaning and then building an authentication system with that in mind you do not need to pass around any session id's or track sessions.

I'm still learning -- if you find anything I have said to be wrong please correct me, and if you learn more post it back here. Thanks.

User · Answer

Update on 16-Feb-2019  The approach mentioned earlier below is essentially  Resource Owner Password Credential  grant type of OAuth2 0  This is an easy way to get up and running  However  with this approach every application in the organization will end up with its own authentication and authorization mechanisms  The recommended approach is  Authorization Code  grant type  Additionally  in my earlier answer below I recommended browser localStorage for storing auth tokens  However  I ve come to believe that cookie is the right option for this purpose  I have detailed my reasons  authorization code grant type implementation approach  security considerations etc  in this StackOverflow answer     I think the following approach can be used for REST service authentication    Create a login RESTful API to accept username and password for authentication  Use HTTP POST method to prevent caching and SSL for security during transit On successful authentication  the API returns two JWTs - one access token  shorter validity  say 30 minutes  and one refresh token  longer validity  say 24 hours  The client  a web based UI  stores the JWTs in local storage and in every subsequent API call passes the access token in  Authorization  Bearer  access token  header The API checks the validity of the token by verifying the signature and expiry date  If the token is valid  check if the user  It interprets the  sub  claim in JWT as username  has access to the API with a cache lookup  If the user is authorized to access the API  execute the business logic If the token is expired  the API returns HTTP response code 400 The client  on receiving 400 401  invokes another REST API with the refresh token in  Authorization  Bearer  refresh token  header to get a new access token   On receiving the call with refresh token  check if the refresh token is valid by checking the signature and the expiry date  If the refresh token is valid  refresh the access right cache of the user from DB and return new access token and refresh token  If the refresh token is invalid  return HTTP response code 400 If a new access token and refresh token are returned  go to step 2  If HTTP response code 400 is returned  the client assumes that the refresh token has expired and asks for username and password from the user For logout  purge the local storage   With this approach we are doing the expensive operation of loading the cache with user specific access right details every 30 minutes  So if an access is revoked or new access is granted  it takes 30 minutes to reflect or a logout followed by a login

User · Answer

It s certainly not about  session keys  as it is generally used to refer to sessionless authentication which is performed within all of the constraints of REST   Each request is self-describing  carrying enough information to authorize the request on its own without any server-side application state   The easiest way to approach this is by starting with HTTP s built-in authentication mechanisms in RFC 2617

User · Answer

Tips valid for securing any web application  If you want to secure your application  then you should definitely start by using HTTPS instead of HTTP  this ensures a creating secure channel between you  amp  the users that will prevent sniffing the data sent back  amp  forth to the users  amp  will help keep the data exchanged confidential   You can use JWTs  JSON Web Tokens  to secure RESTful APIs  this has many benefits when compared to the server-side sessions  the benefits are mainly   1- More scalable  as your API servers will not have to maintain sessions for each user  which can be a big burden when you have many sessions   2- JWTs are self contained  amp  have the claims which define the user role for example  amp  what he can access  amp  issued at date  amp  expiry date  after which JWT won t be valid   3- Easier to handle across load-balancers  amp  if you have multiple API servers as you won t have to share session data nor configure server to route the session to same server  whenever a request with a JWT hit any server it can be authenticated  amp  authorized  4- Less pressure on your DB as well as you won t have to constantly store  amp  retrieve session id  amp  data for each request  5- The JWTs can t be tampered with if you use a strong key to sign the JWT  so you can trust the claims in the JWT that is sent with the request without having to check the user session  amp  whether he is authorized or not  you can just check the JWT  amp  then you are all set to know who  amp  what this user can do   Many libraries provide easy ways to create  amp  validate JWTs in most programming languages  for example  in node js one of the most popular is jsonwebtoken  Since REST APIs generally aims to keep the server stateless  so JWTs are more compatible with that concept as each request is sent with Authorization token that is self contained  JWT  without the server having to keep track of user session compared to sessions which make the server stateful so that it remembers the user  amp  his role  however  sessions are also widely used  amp  have their pros  which you can search for if you want   One important thing to note is that you have to securely deliver the JWT to the client using HTTPS  amp  save it in a secure place  for example in local storage    You can learn more about JWTs from this link

User · Answer

Enough already is said on this topic by good folks here  But here is my 2 cents    There are 2 modes of interaction    human-to-machine  HTM  machine-to-machine  MTM    The machine is the common denominator  expressed as the REST APIs  and the actors clients being either the humans or the machines   Now  in a truly RESTful architecture  the concept of statelessness implies that all relevant application states  meaning the client side states  must be supplied with each and every request  By relevant  it is meant that whatever is required by the REST API to process the request and serve an appropriate response    When we consider this in the context of human-to-machine applications   browser-based  as Skrebbel points out above  this means that the  web  application running in the browser will need to send its state and relevant information with each request it makes to the back end REST APIs    Consider this  You have a data information platform exposed asset of REST APIs  Perhaps you have a self-service BI platform that handles all the data cubes  But you want your  human  customers to access this via  1  web app   2  mobile app  and  3  some 3rd party application  In the end  even chain of MTMs leads up to HTM - right  So human users remain at the apex of information chain   In the first 2 cases  you have a case for human-to-machine interaction  the information being actually consumed by a human user  In the last case  you have a machine program consuming the REST APIs    The concept of authentication applies across the board  How will you design this so that your REST APIs are accessed in a uniform  secured manner  The way I see this  there are 2 ways   Way-1    There is no login  to begin with  Every request performs the login The client sends its identifying parameters   the request specific parameters with each request The REST API takes them  turns around  pings the user store  whatever that is  and confirms the auth If the auth is established  services the request  otherwise  denies with appropriate HTTP status code Repeat the above for every request across all the REST APIs in your catalog   Way-2    The client begins with an auth request  A login REST API will handle all such requests It takes in auth parameters  API key  uid pwd or whatever you choose  and verifies auth against the user store  LDAP  AD  or MySQL DB etc   If verified  creates an auth token and hands it back to the client caller The caller then sends this auth token   request specific params with every subsequent request to other business REST APIs  until logged out or until the lease expires   Clearly  in Way-2  the REST APIs will need a way to recognize and trust the token as valid  The Login API performed the auth verification  and therefore that  valet key  needs to be trusted by other REST APIs in your catalog   This  of course  means that the auth key token will need to be stored and shared among the REST APIs  This shared  trusted token repository can be local federated whatever  allowing REST APIs from other organizations to trust each other    But I digress    The point is  a  state   about the client s authenticated status  needs to be maintained and shared so that all REST APIs can create a circle of trust  If we do not do this  which is the Way-1  we must accept that an act of authentication must be performed for any all requests coming in    Performing authentication is a resource-intensive process  Imagine executing SQL queries  for every incoming request  against your user store to check for uid pwd match  Or  to encrypt and perform hash matches  the AWS style   And architecturally  every REST API will need to perform this  I suspect  using a common back-end login service  Because  if you don t  then you litter the auth code everywhere  A big mess    So more the layers  more latency   Now  take Way-1 and apply to HTM  Does your  human  user really care if you have to send uid pwd hash or whatever with every request  No  as long as you don t bother her by throwing the auth login page every second  Good luck having customers if you do  So  what you will do is to store the login information somewhere on the client side  in the browser  right at the beginning  and send it with every request made  For the  human  user  she has already logged in  and a  session  is available  But in reality  she is authenticated on every request    Same with Way-2  Your  human  user will never notice  So no harm was done   What if we apply Way-1 to MTM  In this case  since its a machine  we can bore the hell out of this guy by asking it submit authentication information with every request  Nobody cares  Performing Way-2 on MTM will not evoke any special reaction  its a damn machine  It could care less   So really  the question is what suits your need  Statelessness has a price to pay  Pay the price and move on  If you want to be a purist  then pay the price for that too  and move on    In the end  philosophies do not matter  What really matters is information discovery  presentation  and the consumption experience  If people love your APIs  you did your job

User · Answer

That s the way to do that  Using OAuth 2 0 for Login   You may use other authentication methods other then Google s as long as it supports OAuth

User · Answer

It s certainly not about  session keys  as it is generally used to refer to sessionless authentication which is performed within all of the constraints of REST   Each request is self-describing  carrying enough information to authorize the request on its own without any server-side application state   The easiest way to approach this is by starting with HTTP s built-in authentication mechanisms in RFC 2617

User · Answer

To be honest with you I ve seen great answers here but something that bothers me a bit is when someone will take the whole Stateless concept to a extreme where it becomes dogmatic  It reminds me of those old Smalltalk fans that only wanted to embrace pure OO and if something is not an object  then you re doing it wrong  Give me a break   The RESTful approach is supposed to make your life easier and reduce the overhead and cost of sessions  try to follow it as it is a wise thing to do  but the minute you follow a discipline  any discipline guideline  to the extreme where it no longer provides the benefit it was intended for  then you re doing it wrong  Some of the best languages today have both  functional programming and object orientation    If the easiest way for you to solve your problem is to store the authentication key in a cookie and send it on HTTP header  then do it  just don t abuse it  Remember that sessions are bad when they become heavy and big  if all your session consists of is a short string containing a key  then what s the big deal   I am open to accept corrections in comments but I just don t see the point  so far  in making our lives miserable to simply avoid keeping a big dictionary of hashes in our server

User · Answer

Tips valid for securing any web application  If you want to secure your application  then you should definitely start by using HTTPS instead of HTTP  this ensures a creating secure channel between you  amp  the users that will prevent sniffing the data sent back  amp  forth to the users  amp  will help keep the data exchanged confidential   You can use JWTs  JSON Web Tokens  to secure RESTful APIs  this has many benefits when compared to the server-side sessions  the benefits are mainly   1- More scalable  as your API servers will not have to maintain sessions for each user  which can be a big burden when you have many sessions   2- JWTs are self contained  amp  have the claims which define the user role for example  amp  what he can access  amp  issued at date  amp  expiry date  after which JWT won t be valid   3- Easier to handle across load-balancers  amp  if you have multiple API servers as you won t have to share session data nor configure server to route the session to same server  whenever a request with a JWT hit any server it can be authenticated  amp  authorized  4- Less pressure on your DB as well as you won t have to constantly store  amp  retrieve session id  amp  data for each request  5- The JWTs can t be tampered with if you use a strong key to sign the JWT  so you can trust the claims in the JWT that is sent with the request without having to check the user session  amp  whether he is authorized or not  you can just check the JWT  amp  then you are all set to know who  amp  what this user can do   Many libraries provide easy ways to create  amp  validate JWTs in most programming languages  for example  in node js one of the most popular is jsonwebtoken  Since REST APIs generally aims to keep the server stateless  so JWTs are more compatible with that concept as each request is sent with Authorization token that is self contained  JWT  without the server having to keep track of user session compared to sessions which make the server stateful so that it remembers the user  amp  his role  however  sessions are also widely used  amp  have their pros  which you can search for if you want   One important thing to note is that you have to securely deliver the JWT to the client using HTTPS  amp  save it in a secure place  for example in local storage    You can learn more about JWTs from this link

User · Answer

I doubt whether the people enthusiastically shouting  HTTP Authentication  ever tried making a browser-based application  instead of a machine-to-machine web service  with REST  no offense intended - I just don t think they ever faced the complications    Problems I found with using HTTP Authentication on RESTful services that produce HTML pages to be viewed in a browser are    user typically gets an ugly browser-made login box  which is very user-unfriendly  you cannot add password retrieval  help boxes  etcetera  logging out or logging in under a different name is a problem - browsers will keep sending authentication information to the site until you close the window timeouts are difficult   A very insightful article that tackles these point by point is here  but this results in a lot of browser-specific javascript hackery  workarounds for workarounds  et cetera  As such  it is also not forward-compatible so will require constant maintenance as new browsers are released  I do not consider that clean and clear design  plus I feel it is a lot of extra work and headache just so that I can enthusiastically show my REST-badge to my friends   I believe cookies are the solution  But wait  cookies are evil  aren t they  No  they re not  the way cookies are often used is evil  A cookie itself is just a piece of client-side information  just like the HTTP authentication info that the browser would keep track of while you browse  And this piece of client-side information is sent to the server at every request  again just like the HTTP Authentication info would be  Conceptually  the only difference is that the content of this piece of client-side state can be determined by the server as part of its response   By making sessions a RESTful resource with just the following rules    A session maps a key to a user id  and possibly a last-action-timestamp for timeouts  If a session exists  then that means that the key is valid  Login means POSTing to  sessions  a new key is set as a cookie Logout means DELETEing  sessions  key   with the overloaded POST  remember  we re a browser  and HTML 5 is a long way to go yet  Authentication is done by sending the key as a cookie at every request and checking whether the session exists and is valid   The only difference to HTTP Authentication  now  is that the authentication key is generated by the server and sent to the client who keeps sending it back  instead of the client computing it from the entered credentials   converter42 adds that when using https  which we should   it is important that the cookie will have its secure flag set so that authentication info is never sent over a non-secure connection  Great point  hadn t seen it myself   I feel that this is a sufficient solution that works fine  but I must admit that I m not enough of a security expert to identify potential holes in this scheme - all I know is that hundreds of non-RESTful web applications use essentially the same login protocol    SESSION in PHP  HttpSession in Java EE  etc    The cookie header contents are simply used to address a server-side resource  just like an accept-language might be used to access translation resources  etcetera  I feel that it is the same  but maybe others don t  What do you think  guys

User · Answer

I doubt whether the people enthusiastically shouting  HTTP Authentication  ever tried making a browser-based application  instead of a machine-to-machine web service  with REST  no offense intended - I just don t think they ever faced the complications    Problems I found with using HTTP Authentication on RESTful services that produce HTML pages to be viewed in a browser are    user typically gets an ugly browser-made login box  which is very user-unfriendly  you cannot add password retrieval  help boxes  etcetera  logging out or logging in under a different name is a problem - browsers will keep sending authentication information to the site until you close the window timeouts are difficult   A very insightful article that tackles these point by point is here  but this results in a lot of browser-specific javascript hackery  workarounds for workarounds  et cetera  As such  it is also not forward-compatible so will require constant maintenance as new browsers are released  I do not consider that clean and clear design  plus I feel it is a lot of extra work and headache just so that I can enthusiastically show my REST-badge to my friends   I believe cookies are the solution  But wait  cookies are evil  aren t they  No  they re not  the way cookies are often used is evil  A cookie itself is just a piece of client-side information  just like the HTTP authentication info that the browser would keep track of while you browse  And this piece of client-side information is sent to the server at every request  again just like the HTTP Authentication info would be  Conceptually  the only difference is that the content of this piece of client-side state can be determined by the server as part of its response   By making sessions a RESTful resource with just the following rules    A session maps a key to a user id  and possibly a last-action-timestamp for timeouts  If a session exists  then that means that the key is valid  Login means POSTing to  sessions  a new key is set as a cookie Logout means DELETEing  sessions  key   with the overloaded POST  remember  we re a browser  and HTML 5 is a long way to go yet  Authentication is done by sending the key as a cookie at every request and checking whether the session exists and is valid   The only difference to HTTP Authentication  now  is that the authentication key is generated by the server and sent to the client who keeps sending it back  instead of the client computing it from the entered credentials   converter42 adds that when using https  which we should   it is important that the cookie will have its secure flag set so that authentication info is never sent over a non-secure connection  Great point  hadn t seen it myself   I feel that this is a sufficient solution that works fine  but I must admit that I m not enough of a security expert to identify potential holes in this scheme - all I know is that hundreds of non-RESTful web applications use essentially the same login protocol    SESSION in PHP  HttpSession in Java EE  etc    The cookie header contents are simply used to address a server-side resource  just like an accept-language might be used to access translation resources  etcetera  I feel that it is the same  but maybe others don t  What do you think  guys

User · Answer

First and foremost  a RESTful web service is STATELESS  or in other words  SESSIONLESS    Therefore  a RESTful service does not have and should not have a concept of session or cookies involved   The way to do authentication or authorization in the RESTful service is by using the HTTP Authorization header as defined in the RFC 2616 HTTP specifications   Every single request should contain the HTTP Authorization header  and the request should be sent over an HTTPs  SSL  connection   This is the correct way to do authentication and to verify the authorization of requests in a HTTP RESTful web services   I have implemented a RESTful web service for the Cisco PRIME Performance Manager application at Cisco Systems   And as part of that web service  I have implemented authentication authorization as well

User · Answer

First and foremost  a RESTful web service is STATELESS  or in other words  SESSIONLESS    Therefore  a RESTful service does not have and should not have a concept of session or cookies involved   The way to do authentication or authorization in the RESTful service is by using the HTTP Authorization header as defined in the RFC 2616 HTTP specifications   Every single request should contain the HTTP Authorization header  and the request should be sent over an HTTPs  SSL  connection   This is the correct way to do authentication and to verify the authorization of requests in a HTTP RESTful web services   I have implemented a RESTful web service for the Cisco PRIME Performance Manager application at Cisco Systems   And as part of that web service  I have implemented authentication authorization as well

User · Answer

Here is a truly and completely RESTful authentication solution    Create a public private key pair on the authentication server  Distribute the public key to all servers  When a client authenticates   3 1  issue a token which contains the following    Expiration time users name  optional  users IP  optional  hash of a password  optional    3 2  Encrypt the token with the private key   3 3  Send the encrypted token back to the user  When the user accesses any API they must also pass in their auth token  Servers can verify that the token is valid by decrypting it using the auth server s public key    This is stateless RESTful authentication   Note  that if a password hash were included the user would also send the unencrypted password along with the authentication token   The server could verify that the password matched the password that was used to create the authentication token by comparing hashes   A secure connection using something like HTTPS would be necessary   Javascript on the client side could handle getting the user s password and storing it client side  either in memory or in a cookie  possibly encrypted with the server s public key

User · Answer

Enough already is said on this topic by good folks here  But here is my 2 cents    There are 2 modes of interaction    human-to-machine  HTM  machine-to-machine  MTM    The machine is the common denominator  expressed as the REST APIs  and the actors clients being either the humans or the machines   Now  in a truly RESTful architecture  the concept of statelessness implies that all relevant application states  meaning the client side states  must be supplied with each and every request  By relevant  it is meant that whatever is required by the REST API to process the request and serve an appropriate response    When we consider this in the context of human-to-machine applications   browser-based  as Skrebbel points out above  this means that the  web  application running in the browser will need to send its state and relevant information with each request it makes to the back end REST APIs    Consider this  You have a data information platform exposed asset of REST APIs  Perhaps you have a self-service BI platform that handles all the data cubes  But you want your  human  customers to access this via  1  web app   2  mobile app  and  3  some 3rd party application  In the end  even chain of MTMs leads up to HTM - right  So human users remain at the apex of information chain   In the first 2 cases  you have a case for human-to-machine interaction  the information being actually consumed by a human user  In the last case  you have a machine program consuming the REST APIs    The concept of authentication applies across the board  How will you design this so that your REST APIs are accessed in a uniform  secured manner  The way I see this  there are 2 ways   Way-1    There is no login  to begin with  Every request performs the login The client sends its identifying parameters   the request specific parameters with each request The REST API takes them  turns around  pings the user store  whatever that is  and confirms the auth If the auth is established  services the request  otherwise  denies with appropriate HTTP status code Repeat the above for every request across all the REST APIs in your catalog   Way-2    The client begins with an auth request  A login REST API will handle all such requests It takes in auth parameters  API key  uid pwd or whatever you choose  and verifies auth against the user store  LDAP  AD  or MySQL DB etc   If verified  creates an auth token and hands it back to the client caller The caller then sends this auth token   request specific params with every subsequent request to other business REST APIs  until logged out or until the lease expires   Clearly  in Way-2  the REST APIs will need a way to recognize and trust the token as valid  The Login API performed the auth verification  and therefore that  valet key  needs to be trusted by other REST APIs in your catalog   This  of course  means that the auth key token will need to be stored and shared among the REST APIs  This shared  trusted token repository can be local federated whatever  allowing REST APIs from other organizations to trust each other    But I digress    The point is  a  state   about the client s authenticated status  needs to be maintained and shared so that all REST APIs can create a circle of trust  If we do not do this  which is the Way-1  we must accept that an act of authentication must be performed for any all requests coming in    Performing authentication is a resource-intensive process  Imagine executing SQL queries  for every incoming request  against your user store to check for uid pwd match  Or  to encrypt and perform hash matches  the AWS style   And architecturally  every REST API will need to perform this  I suspect  using a common back-end login service  Because  if you don t  then you litter the auth code everywhere  A big mess    So more the layers  more latency   Now  take Way-1 and apply to HTM  Does your  human  user really care if you have to send uid pwd hash or whatever with every request  No  as long as you don t bother her by throwing the auth login page every second  Good luck having customers if you do  So  what you will do is to store the login information somewhere on the client side  in the browser  right at the beginning  and send it with every request made  For the  human  user  she has already logged in  and a  session  is available  But in reality  she is authenticated on every request    Same with Way-2  Your  human  user will never notice  So no harm was done   What if we apply Way-1 to MTM  In this case  since its a machine  we can bore the hell out of this guy by asking it submit authentication information with every request  Nobody cares  Performing Way-2 on MTM will not evoke any special reaction  its a damn machine  It could care less   So really  the question is what suits your need  Statelessness has a price to pay  Pay the price and move on  If you want to be a purist  then pay the price for that too  and move on    In the end  philosophies do not matter  What really matters is information discovery  presentation  and the consumption experience  If people love your APIs  you did your job

User · Answer

To answer this question from my understanding...

An authentication system that uses REST so that you do not need to actually track or manage the users in your system. This is done by using the HTTP methods POST, GET, PUT, DELETE. We take these 4 methods and think of them in terms of database interaction as CREATE, READ, UPDATE, DELETE (but on the web we use POST and GET because that is what anchor tags support currently). So treating POST and GET as our CREATE/READ/UPDATE/DELETE (CRUD) then we can design routes in our web application that will be able to deduce what action of CRUD we are achieving.

For example, in a Ruby on Rails application we can build our web app such that if a user who is logged in visits http://store.com/account/logout then the GET of that page can viewed as the user attempting to logout. In our rails controller we would build an action in that logs the user out and sends them back to the home page.

A GET on the login page would yield a form. a POST on the login page would be viewed as a login attempt and take the POST data and use it to login.

To me, it is a practice of using HTTP methods mapped to their database meaning and then building an authentication system with that in mind you do not need to pass around any session id's or track sessions.

I'm still learning -- if you find anything I have said to be wrong please correct me, and if you learn more post it back here. Thanks.

User · Answer

To answer this question from my understanding...

An authentication system that uses REST so that you do not need to actually track or manage the users in your system. This is done by using the HTTP methods POST, GET, PUT, DELETE. We take these 4 methods and think of them in terms of database interaction as CREATE, READ, UPDATE, DELETE (but on the web we use POST and GET because that is what anchor tags support currently). So treating POST and GET as our CREATE/READ/UPDATE/DELETE (CRUD) then we can design routes in our web application that will be able to deduce what action of CRUD we are achieving.

For example, in a Ruby on Rails application we can build our web app such that if a user who is logged in visits http://store.com/account/logout then the GET of that page can viewed as the user attempting to logout. In our rails controller we would build an action in that logs the user out and sends them back to the home page.

A GET on the login page would yield a form. a POST on the login page would be viewed as a login attempt and take the POST data and use it to login.

To me, it is a practice of using HTTP methods mapped to their database meaning and then building an authentication system with that in mind you do not need to pass around any session id's or track sessions.

I'm still learning -- if you find anything I have said to be wrong please correct me, and if you learn more post it back here. Thanks.

User · Answer

The  very insightful  article mentioned by  skrebel   http   www berenddeboer net rest authentication html   discusses a convoluted but really broken method of authentication   You may try to visit the page  which is supposed to be viewable only to authenticated user  http   www berenddeboer net rest site authenticated html without any login credentials    Sorry I can t comment on the answer    I would say REST and authentication simply do not mix  REST means stateless but  authenticated  is a state  You cannot have them both at the same layer  If you are a RESTful advocate and frown upon states  then you have to go with HTTPS  i e  leave the security issue to another layer

User · Answer

I think restful authentication involves the passing of an authentication token as a parameter in the request  Examples are the use of apikeys by api s  I don t believe the use of cookies or http auth qualifies

User · Answer

Using a Public key infrastruction in which the registration of a key involves proper binding ensures that the public key is bound to the individual to which it is assigned in a way that ensures non-repudiation  See http   en wikipedia org wiki Public key infrastructure   If you follow the proper PKI standards  the person or agent who improperly uses the stolen key can be identified and locked out  If the agent is required to use a certificate  the binding gets pretty tight  A clever and quick-moving thief can escape  but they leave more crumbs

User · Answer

How to handle authentication in a RESTful Client-Server architecture is a matter of debate   Commonly  it can be achieved  in the SOA over HTTP world via    HTTP basic auth over HTTPS  Cookies and session management  Token in HTTP headers  e g  OAuth 2 0   JWT   Query Authentication with additional signature parameters    You ll have to adapt  or even better mix those techniques  to match your software architecture at best   Each authentication scheme has its own PROs and CONs  depending on the purpose of your security policy and software architecture   HTTP basic auth over HTTPS  This first solution  based on the standard HTTPS protocol  is used by most web services   GET  spec html HTTP 1 1 Host  www example org Authorization  Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ     It s easy to implement  available by default on all browsers  but has some known drawbacks  like the awful authentication window displayed on the Browser  which will persist  there is no LogOut-like feature here   some server-side additional CPU consumption  and the fact that the user-name and password are transmitted  over HTTPS  into the Server  it should be more secure to let the password stay only on the client side  during keyboard entry  and be stored as secure hash on the Server    We may use Digest Authentication  but it requires also HTTPS  since it is vulnerable to MiM or Replay attacks  and is specific to HTTP   Session via Cookies  To be honest  a session managed on the Server is not truly Stateless   One possibility could be to maintain all data within the cookie content  And  by design  the cookie is handled on the Server side  Client  in fact  does even not try to interpret this cookie data  it just hands it back to the server on each successive request   But this cookie data is application state data  so the client should manage it  not the server  in a pure Stateless world   GET  spec html HTTP 1 1 Host  www example org Cookie  theme light  sessionToken abc123   The cookie technique itself is HTTP-linked  so it s not truly RESTful  which should be protocol-independent  IMHO  It is vulnerable to MiM or Replay attacks   Granted via Token  OAuth2   An alternative is to put a token within the HTTP headers so that the request is authenticated  This is what OAuth 2 0 does  for instance  See the RFC 6749    GET  resource 1 HTTP 1 1  Host  example com  Authorization  Bearer mF 9 B5f-4 1JqM   In short  this is very similar to a cookie and suffers to the same issues  not stateless  relying on HTTP transmission details  and subject to a lot of security weaknesses - including MiM and Replay - so is to be used only over HTTPS  Typically  a JWT is used as a token   Query Authentication  Query Authentication consists in signing each RESTful request via some additional parameters on the URI  See this reference article    It was defined as such in this article      All REST queries must be authenticated by signing the query parameters   sorted in lower-case  alphabetical order using the private credential   as the signing token  Signing should occur before URL encoding the   query string    This technique is perhaps the more compatible with a Stateless architecture  and can also be implemented with a light session management  using in-memory sessions instead of DB persistence    For instance  here is a generic URI sample from the link above   GET  object apiKey Qwerty2010   should be transmitted as such   GET  object timestamp 1261496500 amp apiKey Qwerty2010 amp signature abcdef0123456789   The string being signed is  object apikey Qwerty2010 amp timestamp 1261496500 and the signature is the SHA256 hash of that string using the private component of the API key   Server-side data caching can be always available  For instance  in our framework  we cache the responses at the SQL level  not at the URI level  So adding this extra parameter doesn t break the cache mechanism   See this article for some details about RESTful authentication in our client-server ORM SOA MVC framework  based on JSON and REST  Since we allow communication not only over HTTP 1 1  but also named pipes or GDI messages  locally   we tried to implement a truly RESTful authentication pattern  and not rely on HTTP specificity  like header or cookies    Later Note  adding a signature in the URI can be seen as bad practice  since for instance it will appear in the http server logs  so it has to be mitigated  e g  by a proper TTL to avoid replays  But if your http logs are compromised  you will certainly have bigger security problems   In practice  the upcoming MAC Tokens Authentication for OAuth 2 0 may be a huge improvement in respect to the  Granted by Token  current scheme  But this is still a work in progress and is tied to HTTP transmission   Conclusion  It s worth concluding that REST is not only HTTP-based  even if  in practice  it s also mostly implemented over HTTP  REST can use other communication layers  So a RESTful authentication is not just a synonym of HTTP authentication  whatever Google answers  It should even not use the HTTP mechanism at all but shall be abstracted from the communication layer  And if you use HTTP communication  thanks to the Let s Encrypt initiative there is no reason not to use proper HTTPS  which is required in addition to any authentication scheme

User · Answer

I think restful authentication involves the passing of an authentication token as a parameter in the request  Examples are the use of apikeys by api s  I don t believe the use of cookies or http auth qualifies

User · Answer

Using a Public key infrastruction in which the registration of a key involves proper binding ensures that the public key is bound to the individual to which it is assigned in a way that ensures non-repudiation  See http   en wikipedia org wiki Public key infrastructure   If you follow the proper PKI standards  the person or agent who improperly uses the stolen key can be identified and locked out  If the agent is required to use a certificate  the binding gets pretty tight  A clever and quick-moving thief can escape  but they leave more crumbs

User · Answer

Here is a truly and completely RESTful authentication solution    Create a public private key pair on the authentication server  Distribute the public key to all servers  When a client authenticates   3 1  issue a token which contains the following    Expiration time users name  optional  users IP  optional  hash of a password  optional    3 2  Encrypt the token with the private key   3 3  Send the encrypted token back to the user  When the user accesses any API they must also pass in their auth token  Servers can verify that the token is valid by decrypting it using the auth server s public key    This is stateless RESTful authentication   Note  that if a password hash were included the user would also send the unencrypted password along with the authentication token   The server could verify that the password matched the password that was used to create the authentication token by comparing hashes   A secure connection using something like HTTPS would be necessary   Javascript on the client side could handle getting the user s password and storing it client side  either in memory or in a cookie  possibly encrypted with the server s public key

User · Answer

How to handle authentication in a RESTful Client-Server architecture is a matter of debate   Commonly  it can be achieved  in the SOA over HTTP world via    HTTP basic auth over HTTPS  Cookies and session management  Token in HTTP headers  e g  OAuth 2 0   JWT   Query Authentication with additional signature parameters    You ll have to adapt  or even better mix those techniques  to match your software architecture at best   Each authentication scheme has its own PROs and CONs  depending on the purpose of your security policy and software architecture   HTTP basic auth over HTTPS  This first solution  based on the standard HTTPS protocol  is used by most web services   GET  spec html HTTP 1 1 Host  www example org Authorization  Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ     It s easy to implement  available by default on all browsers  but has some known drawbacks  like the awful authentication window displayed on the Browser  which will persist  there is no LogOut-like feature here   some server-side additional CPU consumption  and the fact that the user-name and password are transmitted  over HTTPS  into the Server  it should be more secure to let the password stay only on the client side  during keyboard entry  and be stored as secure hash on the Server    We may use Digest Authentication  but it requires also HTTPS  since it is vulnerable to MiM or Replay attacks  and is specific to HTTP   Session via Cookies  To be honest  a session managed on the Server is not truly Stateless   One possibility could be to maintain all data within the cookie content  And  by design  the cookie is handled on the Server side  Client  in fact  does even not try to interpret this cookie data  it just hands it back to the server on each successive request   But this cookie data is application state data  so the client should manage it  not the server  in a pure Stateless world   GET  spec html HTTP 1 1 Host  www example org Cookie  theme light  sessionToken abc123   The cookie technique itself is HTTP-linked  so it s not truly RESTful  which should be protocol-independent  IMHO  It is vulnerable to MiM or Replay attacks   Granted via Token  OAuth2   An alternative is to put a token within the HTTP headers so that the request is authenticated  This is what OAuth 2 0 does  for instance  See the RFC 6749    GET  resource 1 HTTP 1 1  Host  example com  Authorization  Bearer mF 9 B5f-4 1JqM   In short  this is very similar to a cookie and suffers to the same issues  not stateless  relying on HTTP transmission details  and subject to a lot of security weaknesses - including MiM and Replay - so is to be used only over HTTPS  Typically  a JWT is used as a token   Query Authentication  Query Authentication consists in signing each RESTful request via some additional parameters on the URI  See this reference article    It was defined as such in this article      All REST queries must be authenticated by signing the query parameters   sorted in lower-case  alphabetical order using the private credential   as the signing token  Signing should occur before URL encoding the   query string    This technique is perhaps the more compatible with a Stateless architecture  and can also be implemented with a light session management  using in-memory sessions instead of DB persistence    For instance  here is a generic URI sample from the link above   GET  object apiKey Qwerty2010   should be transmitted as such   GET  object timestamp 1261496500 amp apiKey Qwerty2010 amp signature abcdef0123456789   The string being signed is  object apikey Qwerty2010 amp timestamp 1261496500 and the signature is the SHA256 hash of that string using the private component of the API key   Server-side data caching can be always available  For instance  in our framework  we cache the responses at the SQL level  not at the URI level  So adding this extra parameter doesn t break the cache mechanism   See this article for some details about RESTful authentication in our client-server ORM SOA MVC framework  based on JSON and REST  Since we allow communication not only over HTTP 1 1  but also named pipes or GDI messages  locally   we tried to implement a truly RESTful authentication pattern  and not rely on HTTP specificity  like header or cookies    Later Note  adding a signature in the URI can be seen as bad practice  since for instance it will appear in the http server logs  so it has to be mitigated  e g  by a proper TTL to avoid replays  But if your http logs are compromised  you will certainly have bigger security problems   In practice  the upcoming MAC Tokens Authentication for OAuth 2 0 may be a huge improvement in respect to the  Granted by Token  current scheme  But this is still a work in progress and is tied to HTTP transmission   Conclusion  It s worth concluding that REST is not only HTTP-based  even if  in practice  it s also mostly implemented over HTTP  REST can use other communication layers  So a RESTful authentication is not just a synonym of HTTP authentication  whatever Google answers  It should even not use the HTTP mechanism at all but shall be abstracted from the communication layer  And if you use HTTP communication  thanks to the Let s Encrypt initiative there is no reason not to use proper HTTPS  which is required in addition to any authentication scheme

User · Answer

It s certainly not about  session keys  as it is generally used to refer to sessionless authentication which is performed within all of the constraints of REST   Each request is self-describing  carrying enough information to authorize the request on its own without any server-side application state   The easiest way to approach this is by starting with HTTP s built-in authentication mechanisms in RFC 2617

User · Answer

It s certainly not about  session keys  as it is generally used to refer to sessionless authentication which is performed within all of the constraints of REST   Each request is self-describing  carrying enough information to authorize the request on its own without any server-side application state   The easiest way to approach this is by starting with HTTP s built-in authentication mechanisms in RFC 2617

User · Answer

The  very insightful  article mentioned by  skrebel   http   www berenddeboer net rest authentication html   discusses a convoluted but really broken method of authentication   You may try to visit the page  which is supposed to be viewable only to authenticated user  http   www berenddeboer net rest site authenticated html without any login credentials    Sorry I can t comment on the answer    I would say REST and authentication simply do not mix  REST means stateless but  authenticated  is a state  You cannot have them both at the same layer  If you are a RESTful advocate and frown upon states  then you have to go with HTTPS  i e  leave the security issue to another layer

User · Answer

I think restful authentication involves the passing of an authentication token as a parameter in the request  Examples are the use of apikeys by api s  I don t believe the use of cookies or http auth qualifies

User · Answer

I think restful authentication involves the passing of an authentication token as a parameter in the request  Examples are the use of apikeys by api s  I don t believe the use of cookies or http auth qualifies

User · Answer

That s the way to do that  Using OAuth 2 0 for Login   You may use other authentication methods other then Google s as long as it supports OAuth

User · Answer

To be honest with you I ve seen great answers here but something that bothers me a bit is when someone will take the whole Stateless concept to a extreme where it becomes dogmatic  It reminds me of those old Smalltalk fans that only wanted to embrace pure OO and if something is not an object  then you re doing it wrong  Give me a break   The RESTful approach is supposed to make your life easier and reduce the overhead and cost of sessions  try to follow it as it is a wise thing to do  but the minute you follow a discipline  any discipline guideline  to the extreme where it no longer provides the benefit it was intended for  then you re doing it wrong  Some of the best languages today have both  functional programming and object orientation    If the easiest way for you to solve your problem is to store the authentication key in a cookie and send it on HTTP header  then do it  just don t abuse it  Remember that sessions are bad when they become heavy and big  if all your session consists of is a short string containing a key  then what s the big deal   I am open to accept corrections in comments but I just don t see the point  so far  in making our lives miserable to simply avoid keeping a big dictionary of hashes in our server

User · Answer

To answer this question from my understanding...

An authentication system that uses REST so that you do not need to actually track or manage the users in your system. This is done by using the HTTP methods POST, GET, PUT, DELETE. We take these 4 methods and think of them in terms of database interaction as CREATE, READ, UPDATE, DELETE (but on the web we use POST and GET because that is what anchor tags support currently). So treating POST and GET as our CREATE/READ/UPDATE/DELETE (CRUD) then we can design routes in our web application that will be able to deduce what action of CRUD we are achieving.

For example, in a Ruby on Rails application we can build our web app such that if a user who is logged in visits http://store.com/account/logout then the GET of that page can viewed as the user attempting to logout. In our rails controller we would build an action in that logs the user out and sends them back to the home page.

A GET on the login page would yield a form. a POST on the login page would be viewed as a login attempt and take the POST data and use it to login.

To me, it is a practice of using HTTP methods mapped to their database meaning and then building an authentication system with that in mind you do not need to pass around any session id's or track sessions.

I'm still learning -- if you find anything I have said to be wrong please correct me, and if you learn more post it back here. Thanks.

User · Answer

Update on 16-Feb-2019  The approach mentioned earlier below is essentially  Resource Owner Password Credential  grant type of OAuth2 0  This is an easy way to get up and running  However  with this approach every application in the organization will end up with its own authentication and authorization mechanisms  The recommended approach is  Authorization Code  grant type  Additionally  in my earlier answer below I recommended browser localStorage for storing auth tokens  However  I ve come to believe that cookie is the right option for this purpose  I have detailed my reasons  authorization code grant type implementation approach  security considerations etc  in this StackOverflow answer     I think the following approach can be used for REST service authentication    Create a login RESTful API to accept username and password for authentication  Use HTTP POST method to prevent caching and SSL for security during transit On successful authentication  the API returns two JWTs - one access token  shorter validity  say 30 minutes  and one refresh token  longer validity  say 24 hours  The client  a web based UI  stores the JWTs in local storage and in every subsequent API call passes the access token in  Authorization  Bearer  access token  header The API checks the validity of the token by verifying the signature and expiry date  If the token is valid  check if the user  It interprets the  sub  claim in JWT as username  has access to the API with a cache lookup  If the user is authorized to access the API  execute the business logic If the token is expired  the API returns HTTP response code 400 The client  on receiving 400 401  invokes another REST API with the refresh token in  Authorization  Bearer  refresh token  header to get a new access token   On receiving the call with refresh token  check if the refresh token is valid by checking the signature and the expiry date  If the refresh token is valid  refresh the access right cache of the user from DB and return new access token and refresh token  If the refresh token is invalid  return HTTP response code 400 If a new access token and refresh token are returned  go to step 2  If HTTP response code 400 is returned  the client assumes that the refresh token has expired and asks for username and password from the user For logout  purge the local storage   With this approach we are doing the expensive operation of loading the cache with user specific access right details every 30 minutes  So if an access is revoked or new access is granted  it takes 30 minutes to reflect or a logout followed by a login

[rest] RESTful Authentication

Examples related to rest

Examples related to authentication

Examples related to restful-authentication

Examples related to rest-security