The auth landscape has a long history of different approaches, several of which build on each other, serve different use cases, or overlap in some way.
There are many different ways to authenticate a user's identity, and just about every one of them has at least one acronym. This article will help you understand some of the more common authentication strategies with the auth landscape, along with when you might want to use each one.
The earliest, and still most common, authentication strategies involve a user sending information directly to the service in question. However, some newer authentication approaches rely on a 3rd party service to provide additional security.
Direct authentication happens when a user sends their authentication information directly to the website they want to access. The user can either send their login information with every request, or the server can create a token that is used to keep the user logged in.
HTTP Basic is one of the earliest methods of authentication, in which the browser sends a username & password in the header of every request. The username and password are put together with a colon, like
username:password, and then Base64 encoded:
This resulting value is then included with every request in the
Authorization header. In our example, the request header would look like:
The HTTP Basic approach is simple, but it does require the browser to always store the username & password directly, which can pose security issues. The server also has to store the password in order to compare it to the incoming password, which is another potential security risk.
For HTTP Basic, there is no way to have a user "sign out" without changing either the username or password, and there is similarly no concept of "signing in", as every request is essentially a sign-in.
Bearer tokens solve many of the problems with HTTP Basic, and are how most websites handle authentication today. In this approach, a username and password are sent one time to "log in". If the credentials are correct, then the server creates and sends a token back to the browser. This token can be totally random characters (sometimes called an "opaque token"), or it can have some information about the user (a "non-opaque token").
For example, when a user logs in, the server might create a random, opaque token for them that looks like
cb0bf23dc6ee4730bd595a21d162efeb. The server will store this token in the database and then send it back to the browser, which will also store the token. Once the browser has this token, the user is considered to be "logged in".
The browser sends this token in the header with each request, often with the prefix
Bearer. So the header for a request might look like:
When the server sees that this token is a match, it can confirm that the user is logged in and can respond accordingly.
In order to "log out" a user, the server can delete its own token or mark it as invalid. The server usually instructs the browser to delete the token too, since it is no longer useful. Once the server has removed its token, any subsequent requests that try to use that token will fail.
#Single Sign On (SSO)
Single Sign On, commonly called SSO, is the ability to authenticate with one server to receive access credentials, and then use those auth credentials with other servers.
It is usually not practical to use a Bearer token with this approach, since the token that gets created by the authentication server would need to be shared with the other servers in realtime. There are 2 main ways of providing Single Sign On: by using a token-based approach similar to direct authentication, or by using a file-based approach where a file is sent between server and browser.
For token-based approaches, JWTs are the most common token type, and OpenID Connect is the most common authentication protocol. OpenID Connect typically uses JWTs for tokens.
#JSON Web Token (JWT)
A JSON Web Token (JWT, pronounced "jot") can be used the same way as an opaque bearer token, but instead of being random, the JWT has some information about the user included.
The information in a JWT is "signed" using a secret phrase. Unlike encryption, signing means that the token's data can be read by the browser or other servers.
A JWT consists of 3 parts: a header, a payload, and a signature. The final token is written as
header.payload.signature, with dots separating each part. This is generated by the authentication server and stored by the browser. In many implementations, the browser then sends the token as a Bearer token:
When a server receives this token, it can verify that the token has not been tampered with if it has the secret phrase used to generate the JWT.
For SSO, this means each server in the organization should have the secret phrase that allows verification of JWTs issued by the authentication server. If a server is configured properly, it can verify incoming JWTs without needing to contact the authentication server, and this enables Single Sign On functionality.
A major downside of using JWTs as access tokens is that the authentication server has no way to instruct other servers to invalidate an existing token. JWTs typically contain information in the payload about when the token expires, but if the users logs out before that time, the token could technically still be used. OpenID Connect solves this problem and also standardizes how to name the attributes in the JWT payload.
#OpenID Connect (OIDC)
OpenID Connect is a protocol for authenticating users that typically uses JWTs.
Instead of using long-lived JWTs as access tokens, OpenID Connect uses two types of tokens:
- ID tokens are issued by the authentication server and only work with the authentication server. ID tokens are typically opaque bearer tokens. A user can send an ID token to the authentication server to obtain a short-lived access token. ID tokens are sometimes called refresh tokens for this reason.
- Access tokens are issued by the authentication server to be used as proof of identity when the browser sends a request to other servers. These are typically short-lived JWTs.
In this scheme, the browser must get a new JWT access token from the authentication server regularly. When the authentication server needs to log the user out, it can invalidate the ID token and stop issuing the user new access tokens. This is a compromise solution: when the user logs out, the server asks the browser to delete its token, but the existing access token is still technically valid because it has not expired yet. However, with a short enough expiration time, the access token will expire quickly and cannot be renewed because the ID token is no longer valid.
OpenID Connect is widely considered to be the most modern popular standard for authentication. However, SAML is an older SSO standard that is still used by many large organizations.
The SAML protocol includes authentication and authorization information in an XML file instead of a token. SAML stands for Security Assertion Markup Language and is pronounced SAM-L.
SAML was developed before JWT based authentication strategies and has some drawback that make it less attractive for modern browser- or mobile-based applications.
SAML uses XML files to authenticate, so it can be used outside of the browser: any system that can send and receive files can technically be authenticated. However, within the context of a browser, SAML is more difficult to work with than tokens and can be susceptible to additional security flaws if not configured properly. In short, SAML is more general-purpose than token-based authentication but is not as specialized as a result.
Because it is harder to work with in the browser, and because its configuration is susceptible to security errors, SAML is not widely used in newer, browser-based applications.
Federated identity, sometimes called Federated Identity Management (FIM), refers to managing a user's identity across one or more systems and servers.
In this sense, all SSO systems are federated identity systems because the authentication server is different than the resource servers. However, the reverse is not true: many FIM systems are not considered to be SSO because there may be multiple authentication servers, or different authentication servers providing different levels of access to the resource servers.
Under the federated identity model, an authentication server is often referred to as an identity provider (IdP) because it is responsible for providing a token that the user can use to prove their identity to other services. A service that the user wants to access is often called a Service Provider (SP) or Resource Server (RS). The user is often (confusingly) called the Resource Owner.
Federated identity commonly uses the same technologies as SSO: either token-based or file-based credentials, with JWT, OpenID Connect, and SAML all in regular use.
And finally, despite the fact that SSO is a subset of federated identity, the terms are sometimes used interchangeably.
Delegated authorization, or delegated access, is when a user allows one service to access their account information on another service. In order to do this, the user must be logged into the first service, and may or may not be logged into the second service.
OAuth 2.0 defines a flow to use when a person wants one service to share their information with another service. It is a popular open standard for access delegation, and it does not address how the user should be authenticated on either service.
With OAuth, a user can grant access to anything related to their account on the first service: a playlist; their contacts or history; their own identity information; or anything else.
The OAuth flow is as follows:
- The user clicks a button indicating they want to allow a first service to share their information with a second service.
- The user is redirected to the first service. If the user is not logged into the first service, they are prompted to log in. OAuth does not dictate how this login process should happen.
- Once the user is logged in, the first service displays a screen indicating which information is about to be shared, and asking the user whether or not they approve.
- If the user approves, the first service sends the requested information to the second service. If the user does not approve, the information is not sent.
- The user is redirected back to the second service, where they can continue.
In this way, the OAuth flow lets a user first know what information is about to be shared, and then allows the user to approve or reject the operation.
OpenID Connect, the authentication protocol discussed above, is built on top of OAuth 2.0. In the case of OpenID Connect, the first server is an authentication server, and the user decides whether to share their identity information with the second server. If the user does share this information, then the second server can rely on the first server to provide authentication.
To quickly set up auth for a web application, try Userfront(opens new window).