If REST applications are supposed to be stateless, how do you manage sessions?

Question

I'm in need of some clarification. I've been reading about REST, and building RESTful applications. According to wikipedia, REST itself is defined to be Representational State Transfer. I therefore don't understand all this stateless gobbledeygook that everyone keeps spewing.

From wikipedia:

At any particular time, a client can either be in transition between application states or "at rest". A client in a rest state is able to interact with its user, but creates no load and consumes no per-client storage on the set of servers or on the network.

Are they just saying don't use session/application level data store???

I get that one goal of REST is to make URI access consistent and available, for instance, instead of hiding paging requests inside posts, making the page number of a request a part of the GET URI. Makes sense to me. But it seems like it is just going overboard saying that no per client data (session data) should ever be stored server side.

What if I had a queue of messages, and my user wanted to read the messages, but as he read them, wanted to block certain senders messages coming through for the duration of his session? Wouldn't it make sense to store this in a place on the server side, and have the server only send messages (or message ID's) that were not blocked by the user?

Do I really have to send the entire list of message senders to block each time I request the new message list? The message list pertinent to me wouldn't/shouldn't even be a publicly available resource in the first place..

Again, just trying to understand this. Someone please clarify.

Update:

I have found a stack overflow question that has an answer that doesn't quite get me all the way there: How to manage state in REST which says that the client state that is important should all be transferred on every request.... Ugg.. seems like a lot of overhead... Is this right??

@S.Lott: I don't think it's intentionally misleading. I think it is a misunderstanding because of confusing terminology. — JUST MY correct OPINION, Jun 24 '10 at 03:23
@JUST MY correct OPINION: Interesting guess. I could not believe such a thing, myself, since it is obvious from that "stateless" means the REST protocol itself is stateless; which says nothing about the underlying application state and updating it with PUT, POST and DELETE requests. — S.Lott, Jun 24 '10 at 10:18
@S.Lott : The HTTP protocol itself is stateless. From what we've discussed below, REST is a viewpoint of how to build your app while not having the webserver handle session state (as opposed to other kinds of state in things like the DB). I didn't even think REST *was* a protocol, but rather a view on how to use the HTTP protocol. I *thought* you guys cleared it up that it was about how to build your application to scale by having the client side store all client specific session data, and making URI accesses as idempotent as possible, except where they shouldn't be. Maybe not... :( — Zak, Jun 24 '10 at 18:35
"Maybe not.." What does that mean? Do you have a new question? Feel free to search SO for it. If it doesn't exist here, then ask it. — S.Lott, Jun 24 '10 at 23:16
Has anyone read Webber, Parastatidis and Robinson's ReST in Practice (or otherwise seen their restbucks example)? The answers below make sense, but surely the coffee orders in the restbucks example are state about a client? The number of orders scales with the number of clients. Where is the line between client state and a resource? — Rikki, Dec 15 '15 at 09:55
Possible duplicate of [Stateless vs Stateful - I could use some concrete information](http://stackoverflow.com/questions/5329618/stateless-vs-stateful-i-could-use-some-concrete-information) — , Sep 20 '16 at 06:18
Possible duplicate of [How to design a RESTful API to check for user's credentials?](http://stackoverflow.com/questions/10145081/how-to-design-a-restful-api-to-check-for-users-credentials) — , Oct 14 '16 at 17:11

score 510 · Answer 1 · edited Jun 20 '20 at 09:12

510

The fundamental explanation is:

No client session state on the server.

By stateless it means that the server does not store any state about the client session on the server side.

The client session is stored on the client. The server is stateless means that every server can service any client at any time, there is no session affinity or sticky sessions. The relevant session information is stored on the client and passed to the server as needed.

That does not preclude other services that the web server talks to from maintaining state about business objects such as shopping carts, just not about the client's current application/session state.

The client's application state should never be stored on the server, but passed around from the client to every place that needs it.

That is where the ST in REST comes from, State Transfer. You transfer the state around instead of having the server store it. This is the only way to scale to millions of concurrent users. If for no other reason than because millions of sessions is millions of sessions.

The load of session management is amortized across all the clients, the clients store their session state and the servers can service many orders of magnitude or more clients in a stateless fashion.

Even for a service that you think will only need in the 10's of thousands of concurrent users, you still should make your service stateless. Tens of thousands is still tens of thousands and there will be time and space cost associated with it.

Stateless is how the HTTP protocol and the web in general was designed to operate and is an overall simpler implementation and you have a single code path instead of a bunch of server side logic to maintain a bunch of session state.

There are some very basic implementation principles:

These are principles not implementations, how you meet these principles may vary.

In summary, the five key principles are:

Give every “thing” an ID
Link things together
Use standard methods
Resources with multiple representations
Communicate statelessly

There is nothing about authentication or authorization in the REST dissertation.

Because there is nothing different from authenticating a request that is RESTful from one that is not. Authentication is irrelevant to the RESTful discussion.

Explaining how to create a stateless application for your particular requirements, is too-broad for StackOverflow.

Implementing Authentication and Authorization as it pertains to REST is even more so too-broad and various approaches to implementations are explained in great detail on the internet in general.

Comments asking for help/info on this will/should just be flagged as No Longer Needed.

edited Jun 20 '20 at 09:12

Community

1
1

answered Jun 23 '10 at 20:35

23

That seems like a pretty bold statement that it is the *only way* to scale to millions of users. Why can't server side sessions be just another service? – Zak Jun 23 '10 at 20:43
27

@Zak: Because millions of sessions is millions of sessions. The point is to avoid the overhead of all this session management. – S.Lott Jun 23 '10 at 20:45
95

it is not boldness it is experience – Jun 24 '10 at 02:18
2

It seems like for an application that you only expect to have, say, 10,000 concurrent users it would be more efficient to use sessions though. 10,000 sessions shouldn't be an issue for one server, and that way you avoid the necessity for database access (user validation) with every request. Shouldn't you move to full REST when your application requires it? – CorayThan Jul 27 '13 at 20:12
21

Nothing in my answer implies a solution based on database access on every request, if you think it does, it is a failing on your part to understand authentication and authorization at that scale. The authentication can be implicit in the state, do you think that facebook does a "database access" on every request of its REST API? Or Google for that matter? **hint: no** – May 31 '14 at 15:56
8

So, if I store the user state in a distributed cache say memcache, and all my web server now does not need to store any state but go and get state from memcache, can I consider this application stateless? – JaskeyLam Nov 21 '14 at 03:18
6

@Jaskey - no you are storing client state how can that be considered stateless. This is really simple, the client must store its own state and pass it around to all the systems that need it. The clients will always be more scalable than anything you can afford to build. – Nov 21 '14 at 03:19
4

If session is saved only in the client side as you suggest, how you achieve PERSISTENCY? the typical example is shopping cart, if a user accidantly close the browser during the shopping, will the data be lost? – GyRo Oct 18 '18 at 14:13
1

addition to the previous commnet: you can store the session in the server's database (https://stackoverflow.com/questions/33786421/rest-shopping-cart) but this is not always the best architecture due to a lot of I/O that may lead performance issues – GyRo Oct 18 '18 at 14:28
1

@GyRo The cart would be stored in a database. It's not really session state; it's data associated with the user that should be saved even when the user exits. If the shopping cart is stored in the server session the user will still lose it anyway when they close their browser (if using the typical server session setup of using a time limited session token saved in a session cookie). You could also store the cart in local storage on the client which would persist for a while. – Nathan Nov 30 '18 at 22:35

score 383 · Accepted Answer · edited Oct 18 '18 at 07:10

383

Statelessness means that every HTTP request happens in complete isolation. When the client makes an HTTP request, it includes all the information necessary for the server to fulfill that request. The server never relies on information from previous requests. If that information was important, the client would have to send it again in subsequent request. Statelessness also brings new features. It’s easier to distribute a stateless application across load-balanced servers. A stateless application is also easy to cache.

There are actually two kinds of state. Application State that lives on the client and Resource State that lives on the server.

A web service only needs to care about your application state when you’re actually making a request. The rest of the time, it doesn’t even know you exist. This means that whenever a client makes a request, it must include all the application states the server will need to process it.

Resource state is the same for every client, and its proper place is on the server. When you upload a picture to a server, you create a new resource: the new picture has its own URI and can be the target of future requests. You can fetch, modify, and delete this resource through HTTP.

Hope this helps differentiate what statelessness and various states mean.

edited Oct 18 '18 at 07:10

Wolverine

1,634
1
15
17

answered Jun 24 '10 at 02:56

6

Does this mean that every time a request is sent the client should send its user/password to authenticate? Because I guess storing a session, even if it is on a shared no-sql db among all servers, is not stateless, or is it? – Carlos Navarro Astiasarán May 13 '17 at 17:50
1

@CarlosNavarroAstiasarán there are various techniques for handling stateless authentication. Google JWT for example. – geoidesic Jan 17 '18 at 15:21
2

@geoidesic: "Because JSON web tokens are stateless, there is no way to invalidate them without storing server state, thus defeating the advantage of stateless tokens." [WIkipedia](https://en.wikipedia.org/wiki/JSON_Web_Token#Vulnerabilities_and_criticism) – ulatekh Aug 23 '18 at 15:04
@ulatekh That’s a gross misrepresentation of what you can do with the tokens. It’s quite simple to store an approved ID along with the token and to only accept tokens that have an approved ID as a claim. Stateless doesn’t mean you can’t something in a database. Essentially you store an ID in the database that must match the same ID in the token. To revoke the token you remove the ID from the database. No state is remembered in the service itself. Or even better you store the sign key with the user in the database and revoke the key. – Andrew T Finnell Aug 24 '19 at 16:46
3

@AndrewTFinnell: If you have to store the approved ID on the server, then it has to be stored on all potential servers that could process the REST login, which could involve a lot of server state across a massively parallel web-server architecture. – ulatekh Aug 30 '19 at 02:30
Sentences from this answer have been copied word-to-word from the book "RESTful Web Design by Leonard Richardson & Sam Ruby". It would be great if you would have given its reference in your answer. Please read this to understand https://meta.stackoverflow.com/a/299918/608170 what Stackoverflow thinks about plagiarism – verisimilitude Jan 09 '21 at 04:58

score 80 · Answer 3 · answered Jun 23 '10 at 20:44

Are they just saying don't use session/application level data store???

No. They aren't saying that in a trivial way.

They're saying do not define a "session". Don't login. Don't logout. Provide credentials with the request. Each request stands alone.

You still have data stores. You still have authentication and authorization. You just don't waste time establishing sessions and maintaining session state.

The point is that each request (a) stands completely alone and (b) can be trivially farmed out to a giant parallel server farm without any actual work. Apache or Squid can pass RESTful requests around blindly and successfully.

What if I had a queue of messages, and my user wanted to read the messages, but as he read them, wanted to block certain senders messages coming through for the duration of his session?

If the user wants a filter, then simply provide the filter on each request.

Wouldn't it make sense to ... have the server only send messages (or message ID's) that were not blocked by the user?

Yes. Provide the filter in the RESTful URI request.

Do I really have to send the entire list of message senders to block each time I request the new message list?

Yes. How big can this "list of message senders to block" be? A short list of PK's?

A GET request can be very large. If necessary, you can try a POST request even though it sounds like a kind of query.

"Don't login. Don't logout. Provide credentials with the request." I always see responses like this in questions about how to remain stateless in a REST API without any details on where/how one should store those credentials on the client. Surely we shouldn't store username and password in local storage! — BeniRose, Jul 11 '16 at 03:13
@BeniRose can we not store a token in localstorage and use that token in requests which will uniquely identify the user? — Nikhil Sahu, Aug 01 '16 at 07:11
Localstorage has a lot of security concerns from what I understand. But also there's a bunch of other concerns with client side sessions, like invalidating tokens, logging a user out, etc. — BeniRose, Aug 02 '16 at 12:58
you use JWT which have a signature, signature verification is fast so you can check the validity of that state. — Archimedes Trajano, Jan 05 '18 at 15:59

score 41 · Answer 4 · edited Nov 04 '14 at 17:11

You are absolutely right, supporting completely stateless interactions with the server does put an additional burden on the client. However, if you consider scaling an application, the computation power of the clients is directly proportional to the number of clients. Therefore scaling to high numbers of clients is much more feasible.

As soon as you put a tiny bit of responsibility on the server to manage some information related to a specific client's interactions, that burden can quickly grow to consume the server.

It's a trade off.

score 33 · Answer 5 · answered Jul 24 '14 at 22:53

Historical view of user application state management

Sessions in the traditional sense keep the user's state in the application inside the server. This may be the current page in a flow or what has been previously entered but not persisted to the main database yet.

The reason for this need was the lack of standards on the client side to effectively maintain the state without making client specific (i.e. browser specific) applications or plug-ins.

HTML5 and XML Header Request has over time standardized the notion of storing complex data including application state in standard way on the client (i.e. browser) side without resorting to going back and forth between the server.

General usage of REST services

REST services are generally called when there is a transaction that needs to be performed or if it needs to retrieve data.

REST services are meant to be called by the client-side application and not the end user directly.

Authenticating

For any request to the server, part of the request should contain the authorization token. How it is implemented is application specific, but in general is either a BASIC or CERTIFICATE form of authentication.

Form based authentication is not used by REST services. However, as noted above REST services are not meant to be called by the user, but by the application. The application needs to manage getting the authentication token. In my case I used cookies with JASPIC with OAuth 2.0 to connect to Google for authentication and simple HTTP Authentication for automated testing. I also used HTTP Header authentication via JASPIC for local testing as well (though the same approach can be performed in SiteMinder)

As per those examples, the authentication is managed on the client side (though SiteMinder or Google would store the authentication session on their end), there's nothing that can be done about that state, but it is not part of the REST service application.

Retrieval requests

Retrieval requests in REST are GET operations where a specific resource is requested and is cacheable. There is no need for server sessions because the request has everything it would need to retrieve the data: authentication and the URI.

Transaction scripts

As noted above, the client-side application itself calls the REST services along with the authentication that it manages on the client side as well.

What this means for REST services [if done correctly] is to take a single request to the REST server will contain everything that is needed for a single user operation that does everything that is needed in a single transaction, a Transaction Script is what the pattern is called.

This is done through a POST request usually, but others such as PUT can also be used.

A lot of contrived examples of REST (I myself did this) tried to follow as much of what has been defined in the HTTP protocol, after going through that I decided to be more pragmatic and left it to GET and POST only. The POST method does not even have to implement the POST-REDIRECT-GET pattern.

Regardless though, as I had noted above, the client-side application will be the one calling the service and it will only call the POST request with all the data when it needs to (not every time). This prevents constant requests to the server.

Polling

Though REST can be used for polling as well, I won't recommend it unless you have to use it because of browser compatibility. For that I would use WebSockets which I had designed an API contract for as well. Another alternative for older browsers is CometD.

score 29 · Answer 6 · answered Jan 10 '16 at 00:37

REST is very abstract. It helps to have some good, simple, real-world examples.

Take for example all major social media apps -- Tumblr, Instagram, Facebook, and Twitter. They all have a forever-scrolling view where the farther you scroll down, the more content you see, further and further back in time. However, we've all experienced that moment where you lose where you were scrolled to, and the app resets you back to the top. Like if you quit the app, then when you reopen it, you're back at the top again.

The reason why, is because the server did not store your session state. Sadly, your scroll position was just stored in RAM on the client.

Fortunately you don't have to log back in when you reconnect, but that's only because your client-side also stored login certificate has not expired. Delete and reinstall the app, and you're going to have to log back in, because the server did not associate your IP address with your session.

You don't have a login session on the server, because they abide by REST.

Now the above examples don't involve a web browser at all, but on the back end, the apps are communicating via HTTPS with their host servers. My point is that REST does not have to involve cookies and browsers etc. There are various means of storing client-side session state.

But lets talk about web browsers for a second, because that brings up another major advantage of REST that nobody here is talking about.

If the server tried to store session state, how is it supposed to identify each individual client?

It could not use their IP address, because many people could be using that same address on a shared router. So how, then?

It can't use MAC address for many reasons, not the least of which because you can be logged into multiple different Facebook accounts simultaneously on different browsers plus the app. One browser can easily pretend to be another one, and MAC addresses are just as easy to spoof.

If the server has to store some client-side state to identify you, it has to store it in RAM longer than just the time it takes to process your requests, or else it has to cache that data. Servers have limited amounts of RAM and cache, not to mention processor speed. Server-side state adds to all three, exponentially. Plus if the server is going to store any state about your sessions then it has to store it separately for each browser and app you're currently logged in with, and also for each different device you use.

So... I hope that you see now why REST is so important for scalability. I hope you can start to see why server-side session state is to server scalability what welded-on anvils are to car acceleration.

Where people get confused is by thinking that "state" refers to, like, information stored in a database. No, it refers to any information that needs to be in the RAM of the server when you're using it.

dkellner · Answer 7 · 2020-10-01T22:14:44.037

17

There is no spoon.

Don't think of statelessness like "sending all your stuff to the server again and again". No way. There will be state, always - database itself is a kind of state after all, you're a registered user, so any set of client-side info won't be valid without the server side. Technically, you're never truly stateless.

The Login Debate

log in every time?

Some mean "send the password each time", that's just plain stupid. Some say "nah of course not, send a token instead" - lo and behold, PHP session is doing almost exactly that. It sends a session id which is a kind of token and it helps you reach your personal stuff without resending u/pw every time. It's also quite reliable and well tested. And yes, convenient, which can turn into a drawback, see next paragraph.

Reduce footprint

should do

A shared storage is a must. Server needs to know at least if someone's logged in or not. (And if you bother the database every time you need to decide this, you're practically doomed.) Shared storages need to be a lot faster than the database. This brings the temptation: okay, I have a very fast storage, why not do everything there? - and that's where things go nasty in the other way.

So you're saying, keep session storage to the minimum?

Again, it's your decision. You can store stuff there for performance reasons (database is almost always slower than Redis), you can store information redundantly, implement your own caching, whatever - just keep in mind that web servers will have a bigger load if you store a lot of rubbish on them. Also, if they break under heavy loads (and they will), you lose valuable information; with the REST way of thinking, all that happens in this case is the client sends the same (!) request again and it gets served this time.

How to do it right then?

Somehow the server must know it's you

edited Oct 01 '20 at 22:14

answered Nov 18 '18 at 19:25

dkellner

5,301
1
31
36

1

"Think and decide, don't let design trends think for you." unfortunately it become very common nowadays to just stupidly follow trends. Sometimes reading SO you will get all the same answers just because of trend. – l00k Nov 06 '19 at 09:36
Yes, I've seen this around many topics and when I realize what's happening, sometimes I stop arguing. Back then everyone was crazy about how content-box is better than border-box; it was one way to show hatred against IE. Then came bootstrap and suddenly everyone was a border-box believer. Trends come but then they go. Use goto, use tables, use iframes, just know what you're doing and why. Trendists will try to bring you down, then they register and pay on your site. World saved again. – dkellner Nov 23 '19 at 19:48
1

@dkellner I didn't understand that part: "Server needs to know at least if someone's logged in or not. (And if you bother the database every time you need to decide this, you're practically doomed.) ". Say you store session data in the database with PHP. Why is querying the DB for login bad (doomed is a strong word) as anyway there will be many subsequent DB request to get the complete user data and other stuff, based on the PHP session ID? In other words, DB queries are inevitable in any case. Also, if you don't receive a PHP session ID, you know the user is unauthenticated, no need to query. – user2923322 May 09 '20 at 04:28
When you have thousands or even millions of users, you can't afford the luxury of connecting to db every time you want to do a keepalive, location update, message poll, or anything that needs a brief check-in. You have to implement these calls without (or with minimal) database access, that's why I'm saying it can be lethal if you build your whole concept around db. Again, there can be cases where a well-designed db solution will work, but the typical programmer will solve anything by saying "okay, first we connect and fetch some user info". Baaaad practice. – dkellner May 11 '20 at 12:31
1

Correct. Also: I tried implementing things such as Login Server myself - just so I know why I don't want to ever do this again. Use standardized patterns, procedures and frameworks. The authentication and authorization processes are pretty technical. But what about "sessions", that do not yet have to be persisted? Well - technically you still can persist them, but mark them as `transient` for as long as e.g. a contract has not been actually "saved" or printed or something. Also: I'd like to keep communication via services instead of via a common database (seen this, too). – Igor Oct 01 '20 at 22:07
1

Why is noone here mentioning JWT tokens and the like? Those tokens contain one's identity, their claims (ie permissions), expiration time and more. With tokens you actually don't need to make a DB lookup and don't need shared state to authenticate a caller. – Christoph Jan 11 '21 at 21:44
@Christoph Good point! I never knew they're a serious solution but now I see they're being used quite often. While it still sounds a bit risky to give a standalone key to a client and accept it without checking against a centralized db, it could be a good solution for relatively short-term situations like repeated calls within one hour or day, thus check against the server less frequently. By all means it is something to consider! – dkellner Jan 11 '21 at 22:39
1

@dkellner Typically you wouldn't give your client this "key". Instead their client authenticates against an identity provider that issues this token, and those tokens typically expire after a certain amount of time. The one important thing that the server needs to do is validate the token, which includes checking the signature against the issuer's certificate. – Christoph Jan 12 '21 at 21:45
@Christoph Sure, it's likely that I don't know enough of this technology because I never used it on battlefield. – dkellner Jan 12 '21 at 21:56

Sam Sirry · Answer 8 · 2016-03-02T11:32:53.090

I see that the basic issue here is mixing up Session with State. And while REST specifies that you should NOT store the State on the server, nothing prevents you from storing a user Session.

Managing the State on the server means that your server knows exactly what the client is doing (what page they're viewing in which section of the application). And this is what you shouldn't need to do.

I agree with the other people saying that you should keep the session storage to a minimum size; and while that's common sense, it's actually also dependent on the application. So, in short, you can still keep a session with cached data to handle the requests with less load on the server, and manage the authentication by providing a temporary authentication/access token for the client to use. Whenever the session/token is expired, generate a new one and ask the client to use it.

Someone might argue that the client should better generate the token. I say it works both ways, and it would depend on the application, and who's going to work with the API.

Also keeping some sensitive session data on the server should be the right way to do. You cannot trust the client to keep their shopping cart that (for example) contains a field named "isFreeGift". Such information should be kept on the server.

The video link provided by Santanu Dey in his answer is helpful. Watch it if you haven't.

Just a side note: It seems all the answers already given seem to disregard the fact that some operations could cause a heavy load on the server. That's relevant in terms of power consumption, hardware consumption, and cost (for servers rented by CPU cycle). A good developer shouldn't be lazy in optimizing their application, even if the operation can be done very quickly on a modern CPU on some rented server for which they don't pay its electricity and maintenance bill.

Althoght the question is a few years old, I hope that my answer would still be helpful.

I generally agree with this sentiment, but there's been a recent trend to claim that even a session identifier shouldn't be stored on the server. I've yet to find out what the alternative solution is, JWT is well touted, but comes with a handful of gotchas: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ — BeniRose, Jul 11 '16 at 15:48

score 12 · Answer 9 · edited Jul 07 '15 at 12:20

Stateless means the state of the service doesn’t persist between subsequent requests and response. Each request carries its own user credentials and is individually authenticated. But in stateful each request is known from any prior request. All stateful requests are session-oriented i.e. each request need to know and retain changes made in previous requests.

Banking application is an example of stateful application. Where user first login then make transaction and logs out. If after logout user will try to make the transaction, he will not be able to do so.

Yes, http protocol is essentially a stateless protocol but to make it stateful we make us of HTTP cookies. So, is SOAP by default. But it can be make stateful likewise, depends upon framework you are using.

HTTP is stateless but still we can maintain session in our java application by using different session tracking mechanism.

Yes, We can also maintain session in webservice whether it is REST or SOAP. It can be implemented by using any third party library or you can implement by our own.

Taken from http://gopaldas.org/webservices/soap/webservice-is-stateful-or-stateless-rest-soap

score 5 · Answer 10 · answered Dec 06 '12 at 14:08

5

Have a look at this presentation.

http://youtu.be/MRxTP-rQ-S8

According to this pattern - create transient restful resources to manage state if and when really needed. Avoid explicit sessions.

answered Dec 06 '12 at 14:08

Santanu Dey

2,806
3
20
37

1

Please read [How do I write a good answer?](http://stackoverflow.com/help/how-to-answer) before attempting to answer more questions. – Mar 16 '18 at 22:14

score 3 · Answer 11 · answered May 22 '15 at 12:44

The major difference between stateless vs Stateful is the data being passed back to the server every time. In case of stateless, the client has to provide all the info so lot of parameters may need to be passed in each request. In Stateful, the cliet passes those parameters once and they are maintained by the server until modified by the client again.

IMO, API should be stateless which gives allows to scale up really quickly.

score 2 · Answer 12 · answered Sep 06 '14 at 11:08

You have to manage client session on the client side. This means that you have to send authentication data with every request, and you probably, but not necessary have an in-memory cache on the server, which pairs auth data to user information like identity, permissions, etc...

This REST statelessness constraint is very important. Without applying this constraint, your server side application won't scale well, because maintaining every single client session will be its Achilles' heel.

If you send auth data with each request, where/how do you store the credentials on the client so the user doesn't have to re-enter it on every request? — Amber, Oct 29 '18 at 22:13

score 1 · Answer 13 · answered Feb 11 '19 at 10:59

When you develop a RESTful service, in order to be logged in you will need your user to be authenticated. A possible option would be to send the username and password each time you intend to do a user action. In this case the server will not store session-data at all.

Another option is to generate a session-id on the server and send it to the client, so the client will be able to send session-id to the server and authenticate with that. This is much much safer than sending username and password each time, since if somebody gets their hand on that data, then he/she can impersonate the user until the username and password is changed. You may say that even the session id can be stolen and the user will be impersonated in that case and you are right. However, in this case impersonating the user will only be possible while the session id is valid.

If the RESTful API expects username and password in order to change username and password, then even if somebody impersonated the user using the session id, the hacker will not be able to lock out the real user.

A session-id could be generated by one-way-locking (encryption) of something which identifies the user and adding the time to the session id, this way the session's expiry time could be defined.

The server may or may not store session ids. Of course, if the server stores the session id, then it would violate the criteria defined in the question. However, it is only important to make sure that the session id can be validated for the given user, which does not necessitate storing the session id. Imagine a way that you have a one-way-encryption of email, user id and some user-specific private data, like favorite color, this would be the first level and somehow adding the username date to the encrypted string and apply a two-way encryption. As a result when a session id is received, the second level could be decrypted to be able to determine which username the user claims to be and whether the session time is right. If this is valid, then the first level of encryption could be validated by doing that encryption again and checking whether it matches the string. You do not need to store session data in order to achieve that.

score 0 · Answer 14 · answered Jul 20 '14 at 13:27

The whole concept is different... You don't need to manage sessions if you are trying to implement RESTFul protocol. In that case it is better to do authentication procedure on every request (whereas there is an extra cost to it in terms of performance - hashing password would be a good example. not a big deal...). If you use sessions - how can you distribute load across multiple servers? I bet RESTFul protocol is meant to eliminate sessions whatsoever - you don't really need them... That's why it is called "stateless". Sessions are only required when you cannot store anything other than Cookie on a client side after a reqest has been made (take old, non Javascript/HTML5-supporting browser as an example). In case of "full-featured" RESTFul client it is usually safe to store base64(login:password) on a client side (in memory) until the applictation is still loaded - the application is used to access to the only host and the cookie cannot be compromised by the third party scripts...

I would stronly recommend to disable cookie authentication for RESTFul sevices... check out Basic/Digest Auth - that should be enough for RESTFul based services.

What is `a client side (in memory) ` and how it is safe to save `base64(login:password)` in client side? — RN Kushwaha, Apr 24 '15 at 06:29
Nothing is defined as "completely safe". However, you can consider to use OAuth2 providing better security than saving base64 string for API request (Basic Auth), if you stick on Basic auth, you can use HTTPS for better security. — felixwcf, May 18 '16 at 09:35
RN Kushwaha, this is the question no one seems to want to answer when they tell you to stop storing session on server and store it in the client. — BeniRose, Jul 11 '16 at 15:51

score 0 · Answer 15 · answered Aug 05 '18 at 07:46

REST is stateless and doesn’t maintain any states between the requests. Client cookies / headers are set to maintain the user state like authentication. Say Client username/password are validated by third part authentication mechanism – 2nd level OTP gerneation etc. Once user get authenticated – headers /cookies comes to rest service end point exposed and we can assume user as auth since user is coming with valid headers/cookies. Now certain info of user like IP is either maintained in the cache and after that if request is coming from same Ip (mac address) for listed resources User is allowed. And cache is maintained for some particular time which get invalidated once time lapses. So either cache can be used or DB entries can be used to persist info b/w the requests.

score 0 · Answer 16 · answered Jan 09 '19 at 07:54

Stateless here means that state or meta data of request is not maintained on server side. By maintaining each request or user's state on server, it would lead to performance bottlenecks. Server is just requested with required attributes to perform any specific operations.

Coming to managing sessions, or giving customize experience to users, it requires to maintain some meta data or state of user likely user's preferences, past request history. This can be done by maintaining cookies, hidden attributes or into session object.

This can maintain or keep track of user's state in the application.

Hope this helps!