Fifty Shades of Membership Sites: Mixing Authentication, Authorization, Session Management and Single Sign-On

Preface

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. (you can read more about how the internet grew here and here)

What makes things worse, is that we have to deal with new ideas, protocols, and technologies – all combine into one big terminology soup.

In this article, I will try to bring some order into terminology chaos and examine the different options we currently have when we want to add membership support to our site.

All membership system can be divided into 3 major components: Authentication, Session Management, and Authorization

Authentication

Authentication covers how the user proves his identity to the site. It can be a simple username/password form, or a special token representing the user identity in another site (this is called single sign-on). After a successful authentication attempt, the site creates a new session for that user.

With authentication, there are two major scenarios relates to where the users are stored: users are stored on our site, or users are stored in another place.

Users are stored on our site (Direct Login)

In this scenario, users are stored on our site, usually inside a table in the database. This means we are both the Identity Provider, as well as the Resource Server (sometimes called Relying party). In this case, users need to authenticate directly against our site, in one (or more) the following ways:

  • Form-based authentication: The most popular way is to provide a form (in a web page) which asks for user credentials. This could work with AJAX or the classic postbacks.
  • Basic authentication:Basic authentication is a mechanism which relies on the browser built-in authentication support. When using this method, users will be prompted by the browser to enter their username and password. Today, however, this method is almost not used for user login (for security reasons, no customization in look or fields, depended on browser support and more). Even for services authentication it is no longer recommended – OAuth is preferred. (note: there are similar HTTP authentication schemes like “digest authentication“, but there almost obsolete these days).
  • Passwordless authentication: This an umbrella term that covers a range of techniques enabling users to login without supplying a password. This is usually implemented with by One-time-password (OTP), “magic” links or Biometric Authentication like Apple’s TouchID.

When using direct login, in addition to validating user credentials, we also need to check if the user is allowed to log in (enabled, active and not locked out). Some implementations also check for security questions, blocked IP address, and expired passwords.

Users are stored in another place (Single sign-on)

Sometimes users are not stored inside a table in our site – they come from external places. This can an external system that manages users (for example Active Directory), or a completely different site. In any case, they do not sit inside our site’s database.

Single sign-on (SSO) is the mechanism which allows users to authenticate into our site, using identity stored in another place. Benefits of using single sign-on include:

  • Mitigate risk for access to 3rd-party sites (user passwords not stored or managed externally)
  • Reduce password fatigue from different user name and password combinations
  • Reduce time spent re-entering passwords for the same identity
  • Reduce IT costs due to a lower number of IT help desk calls about passwords
  • Sharing identities between different sites and systems

SSO implementations can be divided into two groups:

  • OS SSO: SSO support is provided by the Operating System, for example, Windows Authentication, WS-Federation, Smart Card.
  • Site SSO: Sites need to implement SSO, for example, SAML and OpenID Connect.

Windows Authentication

In some cases the SSO is provided by the operating system, for example Windows Authentication allows office workers to enter Intranet sites automatically with their logged-in windows user (which is stored inside Active Directory). This means sites do not have to manage their user’s info (although they can if they want to).

But Windows Authentication has its own limitation. It was built on Microsoft technologies stack which required a specific OS (Windows), browser (IE), the server (IIS) and user store (Active Directory). For this reason, windows authentication (and similarly WS-Federation) can only work within enterprise scenarios, and couldn’t be used on the “wild”, consumer-facing, Internet.

In order to bypass those limitations, and enable cross-organization SSO, SAML protocol was created.

SAML

Security Assertion Markup Language (SAML), was created in 2002 in order to allow cross-organization SSO. This meant employees from one organization could use their identity in another organization systems, for example, Windows users could use Salesforce without the need to log in. This sharing of identities between different organizations is also called Federated identity.

SAML support transferring user identity via server-to-server communication (back-channel) and also directly via the browser (Web Browser SSO profile). However, the implementation was complicated and it failed to meet new requirements:

  • Poor user experience: the SSO process requires many page redirects (postbacks)
  • Difficult to understand and implement: It is based on SOAP, a complicated protocol on its own.
  • No native mobile support: SAML was created in 2002 (5 years before the first iPhone), which is why it is very difficult for mobile devices to use SAML.
  • No REST API support: on the server side, SAML was designed to work with old WS-* and SOAP services which are obsolete now (they have been replaced with REST APIs).
  • Can’t be used for session management: Since they are based on XML, SAML tokens are too big to be sent with every request, which is now required for mobile, single-page, and REST-based applications.

Clarification: SAML protocol was never meant to use for session management, it is an SSO protocol which can be used for authentication and authorization. But with the rise of mobile and SPA, it was no longer possible to only use cookies for session management. A token-based authentication solution was required, however since SAML tokens were too big, JWT format was invented instead. You can read more about tokens, claims, and client-based sessions in this series.

SAML development has stopped in 2005 – no one is working on a new version of the standard or develop new technologies with SAML. All new implantation is now based on OAuth & OpenID Connect, which means SAML can be considered a legacy protocol.

OpenID Connect

OpenID is an SSO protocol designed to allow us to log into one site with identity stored on another site (for example “login with Facebook”). In contrast to SAML, which was created for enterprises and business scenarios, OpenID is more end-user focused and was meant allow using Federated identity outside of work.

The current version of OpenID is called OpenID Connect 1.0. It replaces the first two versions of OpenID (V1 and V2) and is much easier to understand, implement, and be used by mobile devices and services.

OpenID Connect is based on the OAuth protocol (explained below), and define a new JWT token type called id_token, which is meant to be used for end-user SSO authentication.

Many major companies support OpenId Connect (to a varying degree) including Google, Microsoft, Oracle, PayPal, Okta and many more.

Tokens & Claims

Another concept directly related to Federated SSO (meaning SSO between different organizations), is the use of tokens and claims. It is important to understand what they are.

Tokens and claims are concepts relating to how identities are transferred between systems. Since the purpose of Federated SSO is to share user identities between different systems, and every system stores and manages their user profile in a different way, a common way to describe the user profile was needed. And this is where claims and tokens come into place.

Claims are assertion we make about the user. They can be the user ID, email, name and everything else we would like to know about the user.
Claims are issued by the Identity Provider (the system which contains the user information). This list of claims is placed inside a container called the token. The token is the container for the user identity and is the thing which is transferred between the two systems.

Sometimes the terms “assertions” are used instead of “claims”, for example in the SAML protocol specification. They mean the same thing.

Tokens are usually signed or encrypted in order to prevent changes to the claims while they are being transferred. JWT is the token format used by modern protocols like OpenID Connect and OAuth.

This concept of storing the user identity as claims is called Claims-based identity and is the basis of modern SSO protocols.

Additional resources:
The Rise and Fall of Server Side Session
What is Claims-Based Authentication?
OAuth vs. SAML vs. OpenID Connect
A Guide to Claims-Based Identity and Access Control
Authentication and Authorization: OpenID vs OAuth2 vs SAML

Smart Cards

Another way to login into (mostly secured) sites is to use smart card. Those are physical cards issued to specific users, usually after identification process.
The smart card contains a chip that stores the user’s private key, login information, and public key certificate for various purposes. The user inserts the card into a smart card reader attached to the computer. The user then types in a personal identification number (PIN) when requested.
In order to use smart cards for site authentication, the OS support, the site and the Identity Provider must all have support and configured to work together. Because of the additional effort and costs involved, smart card authentication is only used for high-security sites. For the majority of public Internet sites, this is not a practical option.

Session Management

Since the basic protocol of the web, HTTP, is stateless, we need a way to “link” all requests belonging to a certain user. This is the session. Sessions are only created after the authentication component successfully validated the user identity and passed the control to the session management component.

The session management component of the membership system is responsible for the entire life-cycle of the user session, including:

  • Creating session objects (client and/or server)
  • Restoring user session in every request
  • (optional) Restoring user session data and roles in every request
  • Controlling session duration by providing ways to limit and extend the session
  • Closing session when the user logs out or after it expired
  • Preventing attacks by validating and revoking session when needed (whitelist, blacklist, securitystamp, monitoring etc)

Session management implementations can be divided into 3 types:

  • Session ID Cookie: The classic server-side based sessions, where clients only store the session ID inside a cookie. Good for classic websites (postback based), especially if using a single domain.
  • Bearer Token (OAuth): The modern OAuth based way, based on an access token. Good for mobile, desktop, server and single-page applications. Less secured for websites.
  • Claims Cookie (JWT): A mix of both options, where JWT tokens are stored inside a session cookie. Allows creating state-less sites, using client-side sessions. Requires both IdP and RP will sit under the same domain.

Please note: The way sessions are managed in a site has nothing to do with how users authenticated themselves to the site! There is a common misconception that the two are related (probably because classic membership systems handled both parts automatically).

Session management is a complicated matter, deserving its own in-depth explanation. Luckily, I’ve written exactly that – a full series covering both Session ID Cookie and Claims Cookie session management types: The Rise and Fall of Server Side Session, which you are encouraged to read. The only thing missing is OAuth.

OAuth

OAuth was created in 2010 in order to enable a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. Currently, only version 2 of the protocol (released 2012) is used, since it’s not backward compatible with OAuth 1.0.

OAuth 2.0 provides authorization and session management standard for web applications, desktop applications, mobile phones, servers, and living room devices. Although OAuth was not specifically designed for user authentication, until OpenID Connect spec was released, many sites used OAuth for end-user SSO purpose (i.e to implement “login with X” feature). This caused several comparability and security issues, which OpenID Connect tries to solve.

OAuth uses JSON Web Tokens (JWT) to transfer information regarding the user permissions and (sometimes) identity, which are called access_token. Because JWT tokens are much smaller than SAML tokens, they can be sent with all of the user requests, making it possible to use them for managing the user session. This way, they can replace cookies as a session management mechanism.

OAuth support using SAML tokens, but only for the initial SSO request (in order to create a session). The rest of the API communication is done with the access_token, which are JWT based. For more information: OAuth 2.0 SAML Bearer Assertion Flow – Salesforce, SAML 2.0 Profile for OAuth 2.0 – IETF Spec

OAuth with OpenID Connect completely replaced SAML everywhere except legacy enterprise systems – for example, Salesforce now support OAuth.

Authorization

Authorization deals with Access control – what kind of data and operations the user is allowed to perform. In order to do so, the authorization component of the system already expects to know who is the user making the request. This means the user must already have an established session – which was created by the session management component – which in turn was the result of a successful authenticated attempt.

When considering authorization scenarios, they can be defined according to where the permissions data is stored.
There are 3 different places:

  • User Session: In case we are using server-side sessions (usually based on Session ID Cookie), normally the user roles or permission are stored in his session data. In this case, authorization can be simply based on the user session (provided by the session component).
  • Token Claims: In case we are using tokens for session management (whether if they arrive from Authorization header (bearer token) or from inside a cookie), we can just use claims extracted from the token in order to authorize the request. Usually, this works by examining the “scopes” claim, but it could be based on any other claim we would like.
  • Database / External System: Regardless of how the session was implemented, we can always use another database or system for authorization. This could be a database where we store our user’s permission (like used in ASP.NET Identity), or even entirely other systems (for example Apache Fortress).

There are several types of access control systems, based on different models. The most common are role-based and attribute-based, but there are other types.

What is important to understand is the authorization component is only responsible for making sure the user has enough permission for the requested data or operation. It is not responsible for making sure if the session is valid or if the user is who he say he is – those are the responsibility of the other two session management component, of which it trusts.

Now that we have seen the various option we have regarding authentication, authorization, session management, and single sign-on, we can start mixing them up in order to achieve our membership system needs.

Question 1: Who is the IdP?

The first thing we need to consider is if we need to implement direct login or SSO. There 3 different scenarios, all depend on the question:

Where are the users stored?

Option A: Inside the site database

This is the most common scenario, where we maintain a “users” table inside our site database. This means we are the Identity Provider (IdP) and require to implement direct login in one of the ways discussed before.

As the IdP, we are responsible for:

  • Storing users profiles including their password in a secure way
  • Validating user credentials and status
  • Registering new users
  • Provide email confirmation and forgot the password
  • Change password and update profile
  • Disable/delete users
  • Enforce password and users policies
  • Provide protection:
    • Lock user after a number of failed login attempts
    • Passwordless authentication, Multi-factor authentication (2FA)
    • IP blocking, abnormal behavior detection (login from the wrong country)

As you can see, creating new IdP system requires a lot of effort and should only be done by security experts. This is why it is better to use web-frameworks and CMS, which comes with an existing users management module.

Option B: In another system, with direct integration

Sometimes we want our site to manage the users, without having to implement the IdP system ourselves. This can be because our platform doesn’t offer adequate support for it, or because identity systems like Active Directory are a more secure place for storing users passwords then databases (for example, more then 4 billion user accounts were stolen from over 4,000 sites databases).

A common example of this setup can be found with sites which choose to store their users inside Active Directory, instead of the site database.

In order to achieve this scenario, there needs to be a direct integration between the site membership code and the external system. For example, when users use the login form in the site in order to submit their login credentials, the site needs to transfer the login request to the Active Directory to know if to allow the request. The same level of deep integration is expected in all other levels of the membership system, including users registration, deletion, and status update – they are all controlled by the users’ storage system.

Note: Even if it’s not technically required in this scenario, many times the site also maintain their own users’ table. This could be in order to add additional user profile information, for performance or other technical reasons (for example maintaining deleted users information). The challenge than revolving around synchronization between the two users databases.

In this scenarios, we are still considered IdP and require to implement direct user login, even though we are not technically responsible for managing the users. This is the case when our site has direct integration with another system – in other words the site stores it’s used inside another system.

Option C: In another system, no direct integration

When we want to allow users to login into our site using an identity they have in another site or system, we need to implement SSO. This means we are using an external Identity Provider (IdP).

The details of the SSO implementation can vary according to which site or system we want to allows users federation. Many of them use industry standards like SAML and OpenID Connect, however, there may be variation in the implementation and some IdP use their own custom SSO mechanism

Note: Even if it’s not technically required in this scenario, many times the site also maintain their own users’ table. This could be in order to add additional user profile information, for performance or other technical reasons (for example maintaining deleted users information). The challenge than revolving around synchronization between the two users databases.

Storing Users in Active Directory vs Windows Authentication:

In the previous scenario, we learned that sites sometimes choose Active Directory to store their members. This may look similar to Windows Authentication, which also depends on Active Directory as the users’ storage system. Some confusion way rise – what is the difference between them and can they be both considered SSO?

The first big difference is regarding the implementation effort – in the second scenario, we have to manually integrate the site membership system into the Active Directory, where when using Windows Authentication this is done automatically by the system for us. But more importantly, we are talking about two entirely different concepts:

When sites choose to use Active Directory to store their users, those user credentials are used for that site only. In contrast, sites using Windows Authentication allow users to log in with their Windows credentials, preventing them the need to create a new user and password in the site. This is why windows authentication is considered an SSO protocols in contrast to “just” using the AD for storing the site users.

Option D: All of the above

Direct login and SSO and not mutually exclusive – in many cases modern sites need to support both options. This is in order to allow users to reuse existing identity they have in another site, while also giving another option for those who don’t have such an identity (or just prefer not to use it for this site).

Implementing a flexible authentication mechanism which supports both user registration and federation can be quite a challenge, and is usually done by the web framework or CMS, or a dedicated Identity and Access Management (IAM) providers like Azure Active Directory and Okta.

Question 2: How The Site Session Is Managed?

Now it’s time to choose a session management system. The primary factor in this decision is what roles we have: are we the Identity Provider (IdP) – and responsible for managing the user identities, or/and are we the Resource Provider (RP) – and responsible for user information and operations.

Scenario A: Classic site, both the IdP and the RP under the same domain

If we are both the IdP and the RP, which is the case in classic membership systems, our best option is the use cookies. Cookies were created for keeping session, and as long as we get the implementation right (including CSRF protection) – it is by far the easiest and secure way for maintaining sessions.

The session cookie can contain either the session ID (for server-side sessions) or the session data itself (user basic profile and permissions) for client-based sessions. Either way, we need to control session life cycle. For an in-depth discussion on how to choose between server and client sessions, please read this article: The Rise and Fall of Server Side Session.

The main advantage of using cookies for sessions is that we don’t need to implement anything on the client-side, and there are many robust battle testes server-side implementations. The downside is that they can only be used in browsers, and only if both the IdP and the RP are under the same domain (including subdomains – for example, if the login page is www.mysite.com/login and our API is in api.mysite.com).

Scenario B: All Other cases

In all other cases we have little choice except using OAuth based session management protocol:

  • If we want to support native mobile device or IoT devices
  • If our site API (services) sits in a different domain (a common case in SPA and Serverless)
  • If we want to provide IdP services for other sites
  • If we only expose API (services) for other sites for operation or data (for example Twilio, Sendgrid, Facebook Graph, Microsoft Graph)
  • If we want an authenticated way for server-to-server communication, or we have Microservices Architecture.

Implementing cookies based authentication is not practical on all of those cases, and OAuth is the most secure alternative for session management and authorization.

Question 3: How Access Control Is Managed?

The final piece of the puzzle is to choose the access control mechanism. If we are using Session ID Cookies for session management, most implementation comes with a built-in authorization mechanism (usually in a form of user “roles”) and we can just use that. If we are using Claims based authentication, whether the token comes from the bearer header or from the session cookie, we can use those claims for that purpose – by comparing the claim value to a fixed value. This claim can be the “scopes” claim, which will make it Role-based Authorization, or any other claim, allowing us to create Attribute-based Authorization.

In case we don’t want to use hard-coded values, we can always delegate the authorization to a 3rd party system, for example Axiomatics, NextLabs, and Visual Guard and some companies offering XACML based dynamic authorization.

Conclusion

When we first started with membership sites, things were relatively simple. Today we have plenty of options to choose from in every aspect of the membership systems, allowing us to tailor the design to better suit our specific site needs. But the more options we want to implement, the more complex our membership system gets. Even in the past creating a secured membership system was a bigger challenge than most developers could handle, and creating such system today (especially if we want advanced features like mobile device support, social logins and Two-factor authentication), it is almost not possible to get it right – and certainly less practical than using an existing solution.

When choosing a membership solution, we can either use an IAM product like Gluu or IdentityServer, or to use a SaaS IAM, like Azure Active Directory or Auth0.

Some IAM also offers session management and client-side library component which we should use if possible. For example IdentityServer uses ASP.NET Core for session management and comes with JavaScript library. On the cloud, Microsoft Azure App Service offers EasyAuth for session management and many client-side libraries.

For more information about different authenticate methods you can read this article.

One Comment

What do you think?