All you need to know about Auth in the Web. Identity and Access Management.

27 min readJun 10, 2022

Nowadays, almost every website requires some form of Authentication and Authorization to access its features and content. And these are vast and complex topics, it’s really what can get you burn down. Protocols, tools, technologies, concepts, and so on… This article aims to demystify the main parts of it. Of course, I can’t cover everything in this article, but don’t worry, I will provide lots of helpful links.

Life before Identity and Access Management systems

In the world of computers, people are trying to get access to resources on another computer for example web apps. In order for a web app to work with people, it needs to know who you are. It needs to know stuff about you. So traditionally it ends up happening if they have a database with all information about the users and so now when you log in to the app it knows all information about you.

But it’s just one app and if you want another app you need to create a separate database for this app where you need to store all information about the users. And now that app can know about you.

Imagine we have more and more apps where we need to know and manage information about the users. And here is a problem.

Each website/app has independent and own database. It’s means all user credentials applies only for this site.

So what is the solution? As you already guess it’s Identity and Access Management system.

And really cool part is now one single user only has to tell the IdM system who they are just once. With IdM we don’t need to worry about creating separate Identities for individual apps.

Identity and Access Management (IAM)

Identity management

The term “identity” is defined as a collection of attributes associated with a specific person or entity in a particular context. A digital identity is a key to access.

Identity management is the process of creating, maintaining, and revoking user accounts and providing the mechanisms used to authenticate users.

Access control or Access management

“Access” refers to what data an “identities” can see and what actions they can perform when the system knows who they are.

Access control or Access management is the process or mechanism of granting or denying use of a resource or performing an actions. And we have two main form it: Role-Based Access Control and Attribute-Based Access Control. And we need to know when to use each of them.

In other words, just because a “Identity” is verified, that doesn’t mean they should be able to access whatever they want within a system or a network.

There are three steps to the access control process:

Identification — The process by which a subject identifies itself to the access control system
Authentication — Verification of the subject’s identity
Authorization — The decision to allow or deny access to an object

The Authentication step usually happens behind the scenes.

And there are three types of “Identity” when it comes to access control for a specific resource:

Authorized — Those who have presented authenticated credentials and have been approved for access to the resource
Unauthorized — Those who have presented authenticated credentials but are not approved for access to the resource
Unknown — Those who have not presented authenticated credentials

What are Identity and access management?

Identity and access management (IAM or IdAM for short) also known as Identity Management (IDM) is a way to tell who a user is and what they are allowed to do. It’s an Identity management and Access control combined together.

Identity and Access Management System verify user identities and control user privileges. IAMs are used to protect online resources from unauthorized access and comprise an important part of a comprehensive security model.

So we can think of Identity and Access Management as getting the right people the right access to the right resources at the right time.

While identity and access management is a simple concept, in theory, many factors need to work together for it to work well in practice. Identity and access management poses many challenges to developers of modern applications. It requires careful planning, design, and development to implement an application. And there is no one solution that can fit each use case.

Before we continue I highly recommend later to checking out this book: Solving Identity Management in Modern Applications

The difference between Identity and Access Management

The difference between identity management and access management can be simplified like this:

Identity Management is all about managing the attributes related to the “Identity”, group of users, or another identity that may require access from time to time.
Access Management is all about evaluating those attributes based on existing policies and making a yes or no access decision based upon those attributes.

Terms we should know

Identification or Identity Proofing

Identity proofing is the process of verifying a identity: confirming that they are who they say they are. This may sound like ordinary authentication, the kind based on a username/password combination, but identity proofing actually comes into play before users get their credentials to access an application or alongside the traditional authentication process.

The ultimate goal of identity proofing is to ensure that a user’s claimed identity matches their actual identity: in other words, that their identity is real and not fictitious. That’s why identity proofing is a first-line defense against today’s attacks on the identity perimeter.

Identification is the first step of access control.

Authentication

Authentication is the process of proving that you are who you say you are and gaining access to a resource or service based on your identity.

Authentication ensures that data is not exposed to the wrong person. To access online content that is not publicly available, a user needs to authenticate.

The three primary authentication factors are:

Something you know — Secret knowledge, such as a password
Something you have — A token or device
Something you are — Unique physical characteristics of a person, such as those that can be detected by a retinal or iris scan, fingerprint scan, or voice analysis”

Most common Authentication methods:

I also recommend checking out Authentication Survival Guide (book)

Authorization

Authorization refers to the process of verifying what a user has access to. We use authorization to manage user access (allowing or blocking user actions).

Authorization vs. authentication: How are they different?

Also, check out How to use HTTP status code in the authorization context?

Identity Provider (IDP)

An identity provider (IdP) is a service that stores and manages digital identities. It’s a server in a foreign domain that can provide identity information to other domains.

Why are IdPs necessary?

Service Provider (SP)

It’s an application/website user try to access.

Session/Cookie-based authentication

A session stores information about the user, such as a unique ID, time of login and expirations, and so on.

By default, when a user leaves a website or closes their browser, their session ends. To keep users from having to log in every time they return, applications can extend sessions by storing session information in a cookie. Sessions end when a user logs out or when session lifetime limits are reached. Resetting a user’s password, email, or phone number also causes the session to expire.

Typical Session-based authentication flow looks like:

User submits login credentials (email/username and password)
Server verifies the credentials against the Database
Server creates a temporary user Session
Server sends a cookie with a Session ID
On each request user sends the cookie with each request (that how cookies works)
On each request server validates the cookie in request against the session store & grand access
When a user logs out, the server destroys the Session and cleans the cookie for the user.

Sookie-based authentication is stateful. This means that an authentication record or session must be kept both server and client-side. The server needs to keep track of active sessions in a database, while on the front-end a cookie is created that holds a session identifier, thus the name cookie based authentication.

Session-based authentication is no longer the best practice. The problem of cookie based authentication is caused by the mechanism of how cookies work. Cons of a cookie based authentication are as blow:

Stateful. Need to store session in a database on server. It’s not good for API. APIs provide one-time resources for authenticated end-users and don’t need to keep track of user sessions. Cookies don’t work perfectly in this case, since they track and verify active sessions.
CORS. Cookies + CORS don’t play well across different domains.
CSRF. You need to prevent your API from CSRF attack.
Mobile platform. Cookies is for web browser. You need to do extra work for mobile native platform which is not easy to implement.

Check out: How to maintain application sessions in different scenarios?

Token-based authentication

Token-based authentication is a protocol which allows users to verify their identity, and in return receive a unique access token.

Typical Token-based authentication flow looks like:

User submits login credentials (email/username and password)
Server verifies the credentials against the Database
Server generates temporary tokens and embeds user data into them (these tokens are called Access Token and Refresh Token. The Access Token will have less expiry time (60 minutes) and Refresh Token will have long expiry (10 days).
Server responds back with these tokens
User stores these tokens on client-side
User sends Access Token along with each request
On each request server validates the Access Token & grand access (if the access token expired the client requests a new Access Token by sending Refresh Token to the server, and the server validates the Refresh token and if it’s valid issues a new access token (and, optionally, a new refresh token). Example of Refresh Token flow check Refresh Token in OAuth 2.0 Authorization Framework
When user logs out, token is cleared from client storage.

Token-based authentication is stateless. The server does not keep a record of which users are logged in or which JWTs have been issued. Instead, every request to the server is accompanied by a token which the server uses to verify the authenticity of the request. The token is generally sent as an addition Authorization header in form of Bearer {JWT}, but can additionally be sent in the body of a POST request or even as a query parameter.

Check out The Benefits of Going Stateless

Typically, single-page apps (such as React, Vue, and AngularJS + Node), native mobile apps (such as iOS and Android), and web APIs benefit most from token-based authentication. Traditional, server-side web applications have traditionally used cookie-based authentication.

Session or Token Authentication

Determining which authentication method to use is a critical factor in developing mobile apps or single-page web applications. While the need to scale with an authentication method that’s mobile-ready will draw many developers to using tokens, the simplicity of cookies may appeal to others. Ultimately, questions regarding cookie vs token authentication methods will be determined by the type of application or web platform being built.

Check out Session vs Token Authentication.

Access Token

Access tokens are used in token-based authentication to allow an application to access an API. It’s a string to access protected resources. It imposes no requirement on the format, structure, or process in which it’s used. But in many cases developers use JSON web token (JWT) standard for Access tokens.

Once an application has received an access token, it will include that token as a credential when making API requests. To do so, it should transmit the access token to the API as a Bearer credential in an HTTP Authorization header and it’s called Bearer Token.

Refresh Token

Refresh Token is a specialized token used to obtain or refresh expired Access Tokens. While Access Tokens are issued by authorization servers and consumed by resource servers, the Refresh Token is both issued and consumed solely by an authorization server.

A Refresh Token represents all the resources to which the resource owner granted access and can be used to obtain access tokens that target either all or just a subset of those resources.

JWT (JSON Web Tokens)

JSON Web Tokens are an open, industry-standard RFC 7519 method for representing claims securely between two parties. What JWT brings to the table is a simple, useful, standard container format

JWT consists of 3 parts:

Header — contains metadata about the token (type, hashing algorithm etc.)
Payload — contains claims (statements about an entity — for example a name) and additional data.
Signature — is the result of the encoded header, the encoded payload, signed against a secret.

We typically use JWT for Authorization or secure exchange of information between parties. And we use it to verify that the sender is who they claim to be.

A better and secure way to store JWT on a Client is in HttpOnly Cookies.

RS256 and HS256 are the two most common algorithms to sign JWTs.

Also, check out the JWT Handbook (book), and The Parts of JWT Security Nobody Talks About (video), and Why JWTs are the worst possible solution for solving web authentication problems? (video)

Events in the Life of an Identity

In any system, the process of establishing a person’s identity and then using this identity later involves multiple stages often referred to as the “identity lifecycle”.

Identity and access provisioning life cycle

The identity and access provisioning life cycle directly address the management of accounts from creation to deletion. When an account is first created, it is provisioned with appropriate privileges. During the useful lifetime of an account, these privileges are often modified and the account needs to be periodically reviewed to ensure that it has not been granted excessive privileges. When the account is no longer being used, such as when a user leaves the company, it should be disabled as soon as possible and deleted when it has been determined that it is not needed.

Let’s look at common events in the life of an Identity:

**Resource:** Solving Identity Management in Modern Applications by Yvonne Wilson and Abhishek Hingnikar

Provisioning and Deprovisioning

Provisioning is the process of making information technology (IT) systems available to users.

Deprovisioning is the process of removing user access to software and network services.

How do provisioning and de-provisioning work?

Authorization

When an account is created, it is often necessary to specify what the account can do, in the form of privileges. We use the term authorization for the granting of privileges that govern what an account is allowed to do.

Authentication

To access online content that is not publicly available, a user needs to authenticate. A user provides an identifier to signify the account they wish to use and enters login credentials for the account.

Access Policy Enforcement

Once a user has been authenticated and associated with an account, it is necessary to enforce an access policy to ensure any actions taken by the user are allowed by the privileges they have been granted. We use the term access policy enforcement for the enforcement of access policy specified by authorization. In other words, authorization specifies what a user or entity is allowed to do, and access policy enforcement checks that a user’s requested actions are allowed by the privileges they’ve been authorized to use.

Sessions

Once a user has been authenticated and authorized, they will perform various actions within an application. Some applications, typically traditional web applications, and sensitive applications, only allow a user to remain active for a limited period of time before requiring the user to authenticate again. They do this by managing a session for the user. A session tracks information such as whether the user has been authenticated, and if so, typically also the authentication mechanism or strength level used, and when authentication occurred, in addition to a user identifier. This enables an application to know when the user should be prompted to reauthenticate.

The length of time a user is allowed to remain active before reauthentication is known as a session limit or session timeout. The session timeout settings will typically vary by the sensitivity of the data in the application. Session limits help protect against users who walk away from their screen without logging off and identity information that may have changed since the session was created. A session limit that forces a user to periodically reauthenticate provides a check that it is still the legitimate user at the keyboard. It can also trigger a renewal of the user’s identity information and account status.

Single Sign-On (SSO)

After a user accesses one application, they may wish to do something else involving another application. Single sign-on (SSO) is the ability to log in once and then access additional protected resources or applications with the same authentication requirements, without having to reenter credentials.

We will dive deeper into SSO a bit later.

Stronger Authentication

Step-up authentication and multi-factor authentication (MFA) both involve authenticating a user with stronger forms of authentication. Some forms of authentication, such as username-password authentication, are considered relatively weak because they involve a single factor, the password, which can be captured and easily used by others.

Logout

When a user is done with an application, they should terminate their session by logging out. At a minimum, the act of logging out should terminate the user’s application session. If they return to the application, they would have to authenticate again before being granted access. In situations where single sign-on is used, there may be multiple sessions to terminate, and it is a design decision as to which sessions should be terminated when the user logs out of one application.

The act of logging out is slightly different than a session timing out. In the former case, the user explicitly requests that their session be terminated. When a session times out, an application may elect to keep the session in a suspended state and reconstitute the session if the user authenticates again.

Account Management and Recovery

During the course of an identity’s lifetime, it may be necessary to change various attributes of the user profile for the identity. For example, a user may need to update their email address or phone number. A user may need to update their name in some circumstances or to periodically change their password or mobile device used in the authentication process. In a company, a user’s profile might be updated to reflect a new position, address, or privileges such as roles. Account management consists of features or processes which enable users and administrators to view and update user profile attributes associated with an identity.

A user may also forget their password or lose a device that is required for an authentication process. If this happens, a user needs to establish new credentials. This requires an alternate means of establishing the user’s ownership of the account before allowing them to set new credentials. Account recovery is a mechanism to validate a user is the legitimate owner of an account through some secondary means and then allow the user to establish new credentials.

Single sign-on (SSO)

Single sign-on (SSO) is an authentication process that allows a user to access multiple applications and services within the same organization or domain using a single set of credentials.

With SSO, a user signs in at a single login screen and can then use several apps. It means once you logged in you don’t need to log in repeatedly for each application linked to the system.

SSO solves a big problem: how to manage the increasing number of users across a whole ecosystem of applications and services.

How does SSO work?

SSO is possible when a set of applications has delegated authentication to the same entity. It works based upon a trust relationship set up between an application, known as the Service Provider, and an Identity Provider. This trust relationship is often based upon a certificate that is exchanged between the Identity Provider and the Service Provider.

The SSO system must communicate with every external app to tell them that the user is signed in.

More:

Federated Identity

To create a better system for the web, Federated Identity was created for Single Sign On (SSO).

Federated Identity (also known as Federated Identity Management or Federated Authentication) allows authorized users to access multiple applications and domains using a single set of credentials. It links a user’s identity across multiple Identity Management Systems so they can access different applications securely and efficiently. When organizations implement Federated Identity solutions, their users can access web applications, partner websites, Active Directory, and other applications without logging in separately every time. It can reduce IT overhead by delegating identity management to a single provider and improve the end-user experience by requiring a single set of credentials to access multiple resources.

Federated identity systems handle several concerns:

Authentication — validating user credentials and establishing the identity of the user.
Authorization — access restrictions (e.g., is the user allowed to access X resource?).
User attributes exchange — deals with data sharing across different user management systems. For instance, fields such as “real name” may be present in multiple systems. A federated identity system prevents data duplication by linking the related attributes.
User management — related to the administration (creation, deletion, update) of user accounts. A federated identity system usually provides the means for administrators (or users) to handle accounts across domains or subsystems.

With federated identity, employees can access multiple accounts across different domains using a common set of credentials. This improves the user experience. Also, since the system is based on trust between federated organizations, it also minimizes security risks.

Federated Identity Management was developed as a set of agreements and standards that help enterprises and applications share user identities. There are several solutions for federated identity management: SAML and OpenID Connect are two of the most common ones.

How Federated Identity works

The user attempts to access a resource controlled by a server.
The user does not have the proper credentials to access the resource, so the server redirects the user to the authorization server. The authorization server is configured to let users log-in using the credentials managed by an identity provider.
The user gets redirected by the authorization server to the identity’s provider log-in screen.
The user logs-in successfully and gets redirected to the authorization server. The authorization server uses the credentials provided by the identity provider to access the credentials required by the resource server.
The user gets redirected to the resource server by the authorization server. The request now has the correct credentials required to access the resource.
The user gets access to the resource successfully.

Components of federation

Identity Provider or IDP — IDP can be federated to multiple SPs.
Service Provider or SP — SP has nothing to do with the authentication of the user. It trusts the IDP to take care of that. All the SP cares about is that the user was authenticated properly.
Assertion — the message that is sent between the IDP and SP. It’s containse attributes that the SP needs to create a user session. And it’s cryptographically signed so the SP can trust that it came from the right IDP.

Federated Identity vs Single Sign-on

FIM and Single Sign-on (SSO) enable organizations to minimize password-related risks and secure their data and improve user experiences. Both kinds of solutions require a single set of credentials to grant the user access to multiple applications. But despite this similarity, these systems operate differently.

With SSO, users can access multiple applications within the same organization or domain using a single set of credentials. SSO is strictly related to the authentication part of a federated identity system. Its only concern is establishing the identity of the user and then sharing that information with each subsystem that requires the data.

Federated Identity goes a step further. It enables users to access applications or platforms across multiple enterprise domains that are part of the federated configuration. Thus, FIM supports SSO and also extends SSO to multiple domains. Also, SSO is a function of FIM, but implementing it doesn’t necessarily allow for FIM.

In simple words, Federated Identity Authentication is an extension of SSO and enables Single Sign-On to applications across multiple domains or organizations. While SSO lets users log into different apps owned by a single organization, Federated Identity does the same thing across multiple organizations.

A good example for us to understand SSO and Federated Identity can be Google.

Let’s open a new browser window in Incognito or Private mode, then let’s go to Google Docs (https://docs.google.com). When you try to go to this URL in your address bar you will see that your URL automatically changed to https://accounts.google.com/signin/v2/identifier...

Google Docs require you to be authenticated to use it. So it redirects you to https://accounts.google.com which is an Identity Provider service. After you enter your credential you will be redirected back to https://docs.google.com and can use it.

Now let’s go to another Google service, for example, Google Drive (https://drive.google.com).

Wow, as you can see Google Drive already know that you are logged in and shows your profile picture in the top-right corner. Here is SSO made it possible.

And as we learned before SSO works for the same domain in our case it's google.com. docs.google.com and drive.google.com just subdomains.

But let’s go to gmail.com or youtube.com (as we can see these are absolutely different domains and they are not subdomains like docs.google.com).

Wow, we also logged in to these services too. And here is Federated Identity.

There are a set of open specifications and protocols that specify how to design an authentication and authorization system. They specify how you should manage identity, move personal data securely, and decide who can access applications and data. Let’s look at the most popular

Security Assertion Markup Language (SAML 2.0)

SAML is an open standard protocol that standardized way to tell external applications and services that a user is who they say they are. It provided a solution for web single-sign-on across domains and Federated Identity.

SAML makes single sign-on (SSO) technology possible by providing a way to authenticate a user once and then communicate that authentication to multiple applications. The most current version of SAML is SAML 2.0.

NOTE: SAML 2.0 only solves the problem of authenticating users but didn’t help with authorization.

SAML is basically a session cookie in your browser that gives you access to web apps. It’s limited in the kinds of device profiles and scenarios you might want to do outside of a web browser.

NOTE: When SAML 2.0 was launched in 2005, it made sense. However, a lot has changed since then. Now we have modern web and native application development platforms. There are Single Page Applications (SPAs) like Gmail/Google Inbox, Facebook, and Twitter. They have different behaviors than your traditional web application, because they make AJAX (background HTTP calls) to APIs. Mobile phones make API calls too, as do TVs, gaming consoles, and IoT devices. SAML SSO isn’t particularly good at any of this.
— Okta Dev

ALERT: To implement SSO by using SAML you need to relay good understanding of this protocol cuz it’s can be prone to exploits if not implemented correctly.
Use SAML only if you have requirements or you can’t adopt OAuth and OpenID Connect!!!

Benefits of SAML Authentication

Improved User Experience — Users only need to sign in one time to access multiple service providers. This allows for a faster authentication process and less expectation of the user to remember multiple login credentials for every application. In the example above, that user could have clicked on any of the other icons in their dashboard and been promptly logged in without ever having to enter more credentials!
Increased Security — SAML provides a single point of authentication, which happens at a secure identity provider. Then, SAML transfers the identity information to the service providers. This form of authentication ensures that credentials are only sent to the IdP directly.
Loose Coupling of Directories — SAML doesn’t require user information to be maintained and synchronized between directories.
Reduced Costs for Service Providers — With SAML, you don’t have to maintain account information across multiple services. The identity provider bears this burden.

SAML Concepts and Terminology

The SAML specifications define the following terms:

Subject — An entity about which security information will be exchanged. A subject usually refers to a person, but can be any entity capable of authentication, including a software program. For the use cases we’ll discuss, the subject is generally a user of an application.
SAML Profile — A specification that defines how to use SAML messages for a business use case such as cross-domain single sign-on.
SAML Identity Provider — A role defined for the SAML cross-domain single sign-on profile. An identity provider is a server which issues SAML assertions about an authenticated subject, in the context of cross- domain single sign-on.
SAML Service Provider — Another role defined for the SAML cross-domain single sign-on profile. A service provider delegates authentication to an identity provider and relies on information about an authenticated subject in a SAML assertion issued by an identity provider in the context of cross-domain single sign-on.
SAML Trust Relationship — An agreement between a SAML service provider and a SAML identity provider whereby the service provider trusts assertions issued by the identity provider.
SAML Protocol Binding — A description of how SAML message elements are mapped onto standard communication protocols, such as HTTP, for transmission between service providers and identity providers. In practice, SAML request and response messages are typically sent over HTTPS using either HTTP-Redirect or HTTP-POST, using the HTTP-Redirect and HTTP-POST bindings, respectively.
SAML Request — request that SP sends to IdP. Example
SAML Response — response that IdP sends to SP. Example
SAML Issuer — EntityID (unique identifier) of the service provider.
Recipient — EntityID (unique identifier) of the service provider.
ID — generated number for identification.
InResponseTo — the ID of the SAML Request that this response belongs to.
Assertion — An XML-based message that contains security information about a subject. It’s XML-formatted tokens that are used to transfer user identity information, such as the authentication, attribute, and entitlement information, in the messages. SAML Assertion message (XML-formatted token) tells a Service Provider that a user is signed in. SAML Assertions contain all the information necessary for a Service Provider to confirm user identity, including the source of the assertion, the time it was issued, and the conditions that make the assertion valid.
SAML Assertion Consumer Service or ACS — responsible for receiving the SAML Response from the IdP. Checking the Assertion signatures and validating the document.
AssertionConsumerServiceURL — the SAML URL interface of the service provider, where the Identity provider sends the authentication token.
Attributes — with SAML Response there’s going to be other information about the User, like first name, last name, email and etc.
Relay State — is a way for IdP to remember where a user was before authentication. It allows the SP to send along, in the SAML Request, where a user was before the user triggered an authentication, the IdP preserves that Relay State and then sends it back to the SP, the Assertion Consumer Service then can determine where that user needs to go after authentication has been completed.
SAML Trust — configuration between IdP and SP. There are certain pieces of information that are shared: signing certificate, Entity ID aka Issuer. This information is shared between SP and IdP so they can have a trust that allows them to validate the communications in SAML Requests and SAML Responses.
SAML Metadata — is a convenience feature that really allows self-configuration between IdP and SP. It means instead of manually grabbing a certificate, different endpoints, EntryId/Issuer information and etc. from IdP to plugin into SP manually and vice versa. The metadata allows you to just share the entire XML configuration file or share the URL to this XML configuration file and then the SP and IdP can self-configure themselves based on the information within this configuration file. It makes a lot less manual work and makes it more convenient.

How does SAML work?

The SAML protocol has 3 entities:

User Agent (for ex. Browser/User)
Service Provider or SP — application you try to access.
Identity Provider or IdP — centralized service that verifies who you are.

This is what a typical flow might look like:

The User Agent makes a request of the Service Provider. The Service Provider then SAML Requests authentication from the Identity Provider. The Identity Provider sends a SAML Assertion to the Service Provider, and the Service Provider can then send a SAML Response to the principal.

Think of SAML authentication as being like an identification card: a short, standardized way to show who someone is. Instead of, say, conducting a series of DNA tests to confirm someone’s identity, it is possible to just glance at their ID card.

SAML SSO works by transferring the user’s identity from one place (the Identity Provider) to another (the Service Provider). This is done through an exchange of digitally signed XML documents.

Here is helpful tools if you are working with SAML.

Identity Provider sharing the user information and the Service Provider just trust this information. Trust between IdP and SP works in two ways.

SAML is not an easy specification. As a matter of fact, it’s five specifications in one:

Metadata — this simply defines the rules of who an identity provider is or service provider. Metadata is XML that follows a schema which is governed by SAML spesification.
Core/Protocols — XML schemas. These schemas describe the messages that are being sent back and forth.
Binding — description of how do we send messages back and forth.
Profile — combinations of protocols, assertions, and bindings that are used together to create a federation and enable federated single sign-on.
Conformance — tells us how to conform to all specifications above.

When configuring SAML you establish a trust relationship between the Service Provider and Identify Provider. A user who wants to access a Service Provider (SP) must first authenticate into Identity Provider (IDP). After the user is successfully authenticated and authorized the Identity Provider generates a SAML Assertion. The Assertion sends to Service Provider and if Service Provider trusts Identity Provider the user allows to access the Application.

More:

OAuth and OpenId Connect

OAuth 2.0 is for authorization. OpenId Connect is for authentication.

What is OAuth?

OAuth it’s an authorization protocol specified by the OAuth 2.0 Authorization Framework for authorization between services. OAuth works over HTTPS and authorizes devices, APIs, servers, and applications with access tokens rather than credentials.

There are two versions of OAuth: OAuth 1.0a and OAuth 2.0. Nowadays, OAuth 2.0 is the most widely used form of OAuth.

Before OAuth, sites would prompt you to enter your username and password directly into a form and they would log in to your data. Learn more about OAuth's Background here.

If you’ve ever seen something like the dialog below, that’s what we’re talking about. This is an application asking if it can access data on your behalf. This is OAuth.

OAuth Concepts and Terminology

OAuth 2.0 defines four roles involved in an authorization request:

Client (the application)— system that requires access to the protected resources. To access resources, the Client must hold the appropriate Access Token.
Resource Owner (the user)— user or system that owns the protected resources and can grant access to them.
Resource Server (the API) — a server that protects the user’s resources and receives access requests from the Client. It accepts and validates an Access Token from the Client and returns the appropriate resources to it.
Authorization server (can be the same server as the API)— the authority that is able to grant access to resources.

OAuth2.0 defines two client types:

Confidential Client — An application that runs on a protected server and can securely store confidential secrets to authenticate itself to an authorization server or use another secure authentication mechanism for that purpose.
Public Client — An application that executes primarily on the user’s client device (native application) or in the client browser and cannot securely store a secret or use other means to authenticate itself to an authorization server.

OAuth 2.0 defines two security tokens and an intermediary authorization code:

Authorization Code — An intermediary, opaque code returned to an application and used to obtain an access token and optionally a refresh token. Each authorization code is used once.
Access Token — a string that a Client uses to make requests to the Resource Server (API). Access tokens do not have to be in any particular format. ID Token vs Access Token
Refresh Token — a string that a Client can use to get a new Access Token without the user’s interaction (has to be stored securely by clients). Learn more about Refresh Tokens and How to Use Them Securely.

Some more terms:

Redirect URIs or Reply URL — is the location where the authorization server sends the user after a user successfully authorizes an application. More.
Scopes — limit an app’s access to a user’s data. It specifies exactly the reason for which access to resources may be granted. More

How does OAuth work?

Client must acquire its own credentials, a client id and client secret, from the Authorization Server in order to identify and authenticate itself when requesting an Access Token.

Using OAuth 2.0, access requests are initiated by the Client, e.g., a mobile app, website, smart TV app, desktop application, etc. The token request, exchange, and response follow this general flow:

The Client requests authorization (authorization request) from the Authorization server, supplying the client id and secret to as identification; it also provides the scopes and an endpoint URI (redirect URI) to send the Access Token or the Authorization Code to.
The Authorization server authenticates the Client and verifies that the requested scopes are permitted.
The Resource owner interacts with the Authorization server to grant access.
The Authorization server redirects back to the Client with either an Authorization Code or Access Token, depending on the grant type, as it will be explained in the next section. A Refresh Token may also be returned.
With the Access Token, the Client requests access to the resource from the Resource Server.

Learn more about OAuth 2.0 here and here.

What is OpenID Connect (OIDC)?

OpenId Connect is a protocol used to authenticate users of an application, and represents those users in standard way.

OpenID Connect is a simple identity layer built on top of the OAuth 2.0 protocol. We can think of OpenID Connect as an extension to OAuth 2.0 that provides clear guidance on how to achieve a functional and secure authentication system.

ID Token

An ID token is an artifact that proves that the user has been authenticated. It was introduced by OpenID Connect (OIDC), an open standard for authentication used by many identity providers such as Google, Facebook and etc.

ID Token and Access Token: What’s the Difference?

Overview of OAuth and OpenId Connect

Also check out:

Conclusion

To summarize all information we learned in this article a recommend to check out this Technical Overview series: Identity and Access Management, SAML 2.0, OAuth 2.0 & OpenID Connect (OIDC)