In the past when we wanted to add a membership section to our site we only had one option – use our platform form-based login. But things today are a lot more complicated. With the increase Internet use, the rise of mobile devices, social network identities and external services, membership system today need to support many complex scenarios.
Up until now, we talked about where to save the “session state” – on the server (part 1) or on the client (part 2). But the user identity and his permissions are not all the data which we may need to store.
In Part 1 (When the Cookie Crumbles) we saw what issues can happen when using Session ID Cookie and storing the session state on the server. In this post, we will learn about client-side sessions, and how they can solve those problems.
Adding membership support to sites has changed drastically over the last decade. Instead of basic authentication with username and password, modern sites are now required to support modern authentication protocols like OAuth, OpenID and occasionally even SAML. Besides bringing new ways for sharing users identities between sites, these protocols also bring a new concept with them – the client-side session. This idea is in the heart of those protocols, and understanding it is the first step in learning how they work.