Single sign-on (SSO) is an authentication scheme that enables users to access multiple applications and services using a single identity. SSO is built upon a concept called federated identity, which allows the sharing of identity information across trusted and independent systems. The two protocols widely used to enable SSO are SAML and OIDC. Security Assertion Markup Language (SAML) is a protocol that allows users to authenticate against multiple applications with one set of login credentials, thereby facilitating SSO. User authentication is handled by a centralized identity provider, where the authentication status is maintained and shared. Read more at SAML 2.0 Authentication. Similar to SAML, OpenID Connect (OIDC) is a protocol often used as an identity layer in conjunction with OAuth 2.0. OIDC enables SSO by allowing users to authenticate against multiple applications using credentials from trusted identity providers, such as Google or Facebook. The respective identity providers handle user authentication and share the authenticated state with interested applications. Read more at Oauth 2.0 + OIDC Authentication.

SAML stands for security assertion markup language. It is a widely used open standard for authentication and authourization between different parties. The advantages of adopting SAML/SSO include single source of identity and enable consistent authentication across services. Centralizing authentication simplifies granting and revoking access across different services. The parties involved in the SAML authentication flow include the principal, the service provider (SP), and the identity provider (IdP). The principal is the user trying to authenticate and tends to have metadata associated to them. Service providers are the services requesting authentication and identity information about the principal. Lastly, identity providers serve as the source of identity information and authentication decision. The relationship between the three can be thought of as IdP authenticates principals and returns identity information to SP. Before authentication can happen, both SP and IdP need to coordinate and exchange setup information. IdP will need to provide the SSO endpoint and public key to the SP for identity decryption upon successful authentication. In exchange, the SP will need to provide IdP an assertion consumer service (ACS) URL. The ACS URL is where the IdP will POST the SAML assertion to along with redirecting the principal to a defined target resource after authentication. The SAML authentication flow starts with the user (the principal) clicking on an "Continue with SSO" button on the SP's landing page. The SP will create and serialize an XML document known as the AuthnRequest, and appends to the IdP SSO endpoint as query parameter before redirecting the principal to the IdP SSO endpoint. The principal will then enter their credentials for authentication. Upon successful authentication, the IdP encrypts the principal's identity information with its private key. It then redirects the principal back to the ACS URL, passing along the encrypted identity information as part of a SAML payload. The SP will receive and decrypt the payload using the corresponding public key before processing the SAML by creating or configuring user session based on SAML. Sequence Diagram saml-flow-sequence-diagram

Sharing data between services in the past requires username and password authentication. Once authenticated, the client service will have full access to all the user’s data on the server. This is no longer considered the best practice for exposing username and password credentials, along with the lack of control over how much data to share. Oauth 2.0 is an authorization framework that leverages OpenID Connect (OIDC) for authentication. Resource sharing using Oauth 2.0 usually includes three or more parties, the resource owner, resource server, and resource client. Although not required, the resource server can also take on the role of an authorization server. The resource-sharing process starts with the resource owner requesting resources via the resource client. The client will invoke the authentication flow with the authorization server (the resource server in this case). This redirects the user to the authorization server where they are presented with a login page. The owner can review what resource is being shared upon successful authentication. Once the owner grants the permission, the authentication server will issue an auth token, which the client will use to request an access token. The client can now access resources on the server within the defined scope using the access token. Some other notable features of Oauth 2.0 include the ability for the owner to revoke or set expiration date on the access token. Sequence Diagram oidc-oauth2-sequence-diagram

JWT (JSON Web Token) is a self-contained token that securely encodes information between parties as a JSON object. One of JWT's primary use cases is for authentication in web applications or APIs. User authentication using JWT begins with the client submitting their username and password. Assuming the user exists and the provided credentials are valid, the next step is to issue an access token and a refresh token by signing the username along with metadata, such as an expiration date, using a server private key. The client can then commence using the access token as part of their requests for protected resources. The resource access flow starts with the client attaching their access token in the "Authorization" header. The server verifies the access token with its corresponding server private key and permits the request to proceed if the provided access token is valid. Access tokens have a short lifespan. Once they expire, the client must use the refresh token, which has a much longer lifespan, to obtain a new access token. The refresh token was originally set in the browser's cookie during the initial authentication and is accessible to the server with every request. When the client wishes to refresh their access token, the server verifies their refresh token. Upon successful verification, the server signs a new access token by encrypting the username with a new expiration date using the server private key.