Authentication vs Authorization and OIDC vs OAuth 2.0 vs SAML

 What is Open Id Connect? What is OAuth? What is SAML? We typically hear these terms thrown around, but what do they really mean? In the following article, I am going to dispel some misconceptions and shed some light on these 3 authentication/authorization protocols.

OAuth - OAuth (or more specifically OAuth 2.0) is a protocol for authorization that enables 3rd party applications to obtain limited access to an HTTP service either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. There are several key components of OAuth 2.0: 

• Resource Owner: The entity that can grant access to a protected resource, typically the end-user.
• Client: The application requesting access to the protected resource on behalf of the resource owner.
• Resource Server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
• Authorization Server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

OAuth calls methods for getting tokens to make requests to the resource server grant types. There are 6 main grant types: 

    1. Authorization Code Grant: Used for server-side applications. It involves an authorization code obtained from the authorization server, which the client then exchanges for an access token. This is a secure method as the authorization code is transmitted via a secure backend channel.

    2. Implicit Grant: Used for client-side applications (e.g., single-page applications) where the client cannot securely store a client secret.

    3. Resource Owner Password Credentials Grant: Used in highly trusted applications where the client can directly obtain the resource owner’s credentials (username and password).

    4. Client Credentials Grant: Used for machine-to-machine (M2M) communication where the client is acting on its own behalf. The client authenticates with the authorization server and directly obtains an access token.

    5. Refresh Token Grant: Used to obtain a new access token when the current access token expires.

    6. Device Authorization Grant (Device Flow): Used for devices with limited input capabilities (e.g., smart TVs).

OpenID Connect :

OpenID Connect (OIDC) is an identity layer on top of the OAuth 2.0 protocol, providing a standardized way to authenticate users and obtain basic user profile information.

How It Works

1. Authorization Request:

   • The client redirects the end-user to the authorization server with a request containing the client ID, requested scope, redirect URI, and response type.
   • Example URL: https://auth.example.com/authorize?response_type=code&client_id=client123&redirect_uri=https://client.example.com/callback&scope=openid profile email

2. Authorization Response:

   • The authorization server authenticates the end-user and obtains their consent for the requested scopes.
   • If successful, the server redirects the end-user back to the client with an authorization code.
   • Example URL: https://client.example.com/callback?code=authorization_code

3. Token Request:

   • The client sends the authorization code, along with its credentials, to the token endpoint of the authorization server to exchange the code for tokens.
   • Example Request:

     http
     POST /token
     Host: auth.example.com
     Authorization: Basic base64(client_id:client_secret)
     Content-Type: application/x-www-form-urlencoded
     
     grant_type=authorization_code&code=authorization_code&redirect_uri=https://client.example.com/callback
     

4. Token Response:

   • The authorization server responds with an ID token and optionally an access token and a refresh token.
   • Example Response:

     
     {
       "access_token": "access_token_value",
       "id_token": "id_token_value",
       "refresh_token": "refresh_token_value",
       "token_type": "Bearer",
       "expires_in": 3600
     }
     

5. UserInfo Request (Optional):

   • The client can use the access token to request additional user profile information from the UserInfo endpoint.
   • Example Request:

     http
     GET /userinfo
     Host: auth.example.com
     Authorization: Bearer access_token_value
     

6. UserInfo Response:

   • The UserInfo endpoint returns claims about the authenticated end-user.
   • Example Response:

     {
       "sub": "248289761001",
       "name": "Jane Doe",
       "given_name": "Jane",
       "family_name": "Doe",
       "preferred_username": "j.doe",
       "email": "janedoe@example.com",
       "picture": "http://example.com/janedoe/me.jpg"
     }
     

    Key Features

• Interoperability: OIDC is designed to work across various platforms and languages.
• RESTful Architecture: Utilizes HTTP and JSON standards, making it easy to implement and integrate.
• Security: Built on OAuth 2.0, leveraging its security features such as scopes and token exchanges.
• User Experience: Supports single sign-on (SSO), providing a seamless authentication experience across multiple applications.

    Use Cases

• Single Sign-On (SSO): Allowing users to log in once and gain access to multiple applications.
• Mobile and Web Applications: Providing a standardized way to authenticate users across different types of applications.
• API Access: Securing API endpoints by ensuring that only authenticated users can access them.

SAML - 

Security Assertion Markup Language (SAML) is an XML-based framework for authentication and authorization between two entities: a service provider (SP) and an identity provider (IdP). It is used to exchange authentication and authorization data securely over the internet.

Key Components

1. Identity Provider (IdP):

• The entity that authenticates a user and asserts their identity to the service provider.

2. Service Provider (SP):

• The entity that provides services to the user and relies on the identity provider to authenticate the user.

3. Principal:

• The user who is being authenticated.

4. Assertions:

• XML documents that contain statements about the authentication, attributes, and authorization of the user.

SAML Assertions

1. Authentication Assertion:

• Confirms that the user has been authenticated by the IdP at a specified time using a particular method.

2. Attribute Assertion:

• Contains specific attributes about the user, such as email address, username, and roles.

3. Authorization Decision Assertion:

• States whether a user is authorized to access a specific resource.

SAML Protocols

1. Authentication Request Protocol:

• Used by the SP to request authentication of a user from the IdP.

2. Assertion Query and Request Protocol:

• Allows an SP to query the IdP for specific assertions about a user.

3. Single Logout Protocol:

• Enables a user to be logged out simultaneously from all services they accessed using SAML SSO.

SAML Bindings

1. HTTP Redirect Binding:

• Encodes SAML messages into URL query parameters for transmission through HTTP GET.

2. HTTP POST Binding:

• Transmits SAML messages within an HTML form using HTTP POST.

3. HTTP Artifact Binding:

• Uses a reference (artifact) to retrieve SAML messages, minimizing the amount of SAML data transmitted via URLs.

4. SOAP Binding:

• Uses Simple Object Access Protocol (SOAP) to transmit SAML messages over HTTP.

SAML Profiles

1. Web Browser SSO Profile:

• The most common profile, enabling Single Sign-On (SSO) for web applications.

2. Enhanced Client or Proxy (ECP) Profile:

• Allows for SSO in non-browser clients.

3. Single Logout Profile:

• Defines how to log out a user from all services using SAML.

4. Artifact Resolution Profile:

• Specifies how to retrieve a SAML assertion from an artifact reference.

SAML SSO Flow

1. User attempts to access a resource on the SP:

• The SP determines that the user needs to be authenticated.

2. SP redirects the user to the IdP:

• The SP generates an authentication request and redirects the user to the IdP’s SSO service.

3. IdP authenticates the user:

• The user authenticates with the IdP, typically by entering their credentials.

4. IdP sends a SAML response to the SP:

• Upon successful authentication, the IdP generates a SAML response containing the authentication assertion.
• The response is sent back to the SP, usually through the user’s browser using HTTP POST or HTTP Redirect binding.

5. SP processes the SAML response:

• The SP validates the SAML response and extracts the assertions.
• The user is granted access to the requested resource.

Security Considerations

1. Digital Signatures:

• SAML assertions and protocol messages are digitally signed to ensure their integrity and authenticity.

2. Encryption:

• SAML assertions and messages can be encrypted to protect sensitive information.

3. Timestamp and Expiration:

• SAML assertions include timestamps and expiration dates to prevent replay attacks.

4. Secure Communication:

• SAML communications typically occur over HTTPS to protect data in transit.

Example Scenario: Web Browser SSO

1. User Accesses Application:

   • User tries to access a web application (SP).

2. Redirect to IdP:

   • The application redirects the user to the IdP for authentication.

3. User Authenticates:

   • The user enters credentials at the IdP login page.

4. SAML Response:

   • Upon successful authentication, the IdP sends a SAML response back to the SP.

5. Access Granted:

   • The SP processes the SAML response, and the user is granted access to the application.

Advantages of SAML

1. Single Sign-On (SSO):

   • Users can authenticate once and access multiple applications without re-entering credentials.

2. Improved Security:

   • Centralized authentication and detailed assertions improve security.

3. Interoperability:

   • Standardized XML format allows interoperability between different systems and platforms.

4. User Convenience:

   • Reduces the need for multiple passwords, improving user experience.