Table of Contents

• Session based authentication
• Token based authentication
• JWT
• OAuth 2.0
• OpenID Connect
• SSO
• SAML
• MFA
• LDAP
• References
• To be added

Session based authentication

• Steps
  • The client sends a login request with credentials
  • The server validates the credentials, creates a session (which includes user-related data), assigns it a unique session ID, stores this session on the server, and sends the session ID to the client.
  • The session ID is sent to the client in a Set-Cookie header, and the browser stores it.
  • Client saves the session id in a cookie
  • On each subsequent request, the browser automatically sends the cookie with the session ID, and the server uses it to retrieve the associated session and validate the user.
• Pros
  • Since session ID’s are stored on the server, if security team suspects an account is compromised, they can invalidate the session
• Cons
  • Needs additional storage space to store these session ID’s (for example cache, database etc.)
  • Session management can introduce scalability challenges in distributed environments, as multiple servers must share access to the session store. This often requires a centralized store (like Redis or a database), adding complexity.

Token based authentication

• Steps
  • The client sends a login request with credentials.
  • If the credentials are valid, the server creates a token (for example JWT) and returns to the client.
  • The client stores the token in session or local storage.
  • On each subsequent request, the client sends this token (for example as Authorization header). The server validates and then processes the request.
• Pros
  • It’s stateless. Server need not store any token, which makes scaling easier in distributed systems.
• Cons
  • Tokens are valid until they expire. So, there is no easy way to revoke a token.

JWT

• It’s one of the common token generation method used in token based authentication mechanism.
• A JWT token has 3 parts
  • Header - type of token (JWT), signing algorithm (HS256)
  • Payload - contains claims such as identity of the user and permissions they are allowed
  • Signature - used to verify the token’s integrity and authenticity

OAuth 2.0

• OAuth 2.0 is an authorization framework that enables third-party applications to obtain limited access to a user’s resources without exposing their credentials.
• OAuth is an authorization protocol whose main focus is to grant access to protected resources. OpenID builds on top of OAuth to add authentication layer.
• Key concepts
  • Resource Owner: The user who owns the data or resource.
  • Client: The third party application that wants to access the resource on the user’s behalf.
  • Authorization Server: Issues access tokens after authenticating and authorizing the user.
  • Resource Server: The server that holds the protected data and accepts access tokens for access.
• Grant Types
  • There are different ways in which a third party app can request access to a protected resource, and these are called grant types. OAuth 2.0 has 4 different grant (flow) types:
    • Authorization Code grant
      • Request users permission - The process starts when the browser sends a request to the Authorization Server. This request is made when the user clicks on any of the Sign in with buttons (Sign in with Google, Facebook etc.). The request mainly contains following parameters
        • response_type: mentions the grant type to be used. In this case, it’s the Authorization Code grant type.
        • client_id: this is obtained when creating an app in the authorization server.
        • redirect_uri: the redirect URL once it is authorized by the authorization server.
        • scope: this list mentions what is the scope of permissions requested by the client.
      • User authorises the request - Once the request is made the user will be seeing a page that asks for users’ login credentials (credentials of the OAuth service provider). The user will log in here, and then they will be presented with another page asking the user whether they want to allow access to those resources or not. Now you might feel that this extra step asking the user to acknowledge again is unnecessary since the user has already authenticated. But the reason this is shown is that the client can request access to different scopes of user information. For example, adding contacts to the scope will the give client access to users contact information. As an end-user I will not know what are the scopes the client has requested for. So in this page, clearly mentions a list of actions that the client can perform once the access is given. For example, you might want to give view access to your contact information but not modify or delete it. This page mentions what the client is capable of doing once you allow access to it.
      • Redirect back to the application - Now after allowing access, the authorization server redirects back to the redirect URL that was provided at the start of the request. Along with this, an authorization code is also provided.
      • Get Access token - Now using this code, the client sends a request to the authorization server to get an access token in return. The client stores this access token and uses it every time to request the protected resource from the resource owner.
    • Implicit Flow grant
      • Designed for browser-based or mobile applications where the client couldn’t securely store a secret. Instead of exchanging an authorization code for a token, the access token is returned directly in the URL fragment after user authorization. This flow is now considered insecure and deprecated, as it exposes tokens in the browser and lacks strong client authentication
    • Resource Owner
      • The user provides their username and password directly to the client, which then sends these credentials to the authorization server to obtain the access tokens.
    • Client Credentials
      • The client authenticates directly with the authorization server using its client_id and client_secret, and receives an access token to access protected resources. This flow is ideal for machine-to-machine (M2M) communication, such as background jobs or service-to-service APIs.
    • Refresh Token grant
      • The Refresh Token Grant is used to obtain a new access token without requiring the user to re-authenticate. After the initial login (usually via the Authorization Code Flow), the client receives both an access token and a refresh token. When the access token expires, the client sends the refresh token to the authorization server to get a new access token, maintaining a seamless user experience without repeated logins. Refresh tokens are long-lived and should be securely stored, as they provide ongoing access.

OpenID Connect

• Open ID Connect is an identity authentication protocol that is an extention of OAuth 2.0.
• It allows third-party applications to verify the identity of the end-user and obtain basic user profile information.
• For example, a news site (Relying Party) wants to add authentication to their site, they can use Open ID Providers (like facebook, google, microsoft). This OIDC provider handles the authentication process and provides the relying party with the user profile information
• Key Concepts
  • Relying party - are the applications that use Open ID service to authenticate users.
  • Open ID Provider - they provide authentication service to relying party
• Steps
  • The user navigates to the page they wish to access (relying party)
  • User is shown a page which asks for authentication. This page displays different OIDC providers (like sign in with google, facebook etc)
  • User clicks on one of the OIDC providers. This takes them to the authentication page of OIDC provider. Here user enters their crendentials.
  • OIDC provider validates the credentails and obtains authorization.
  • OIDC provider sends an identity token (and access token also) to the relying party.
  • Relying party validtes these token to confirm users’ identity.
  • User is then granted access to the application.
• OIDC vs OAuth 2.0
  • OAuth is about authorizing for resource access and sharing. OIDC is about authentication.

SSO

• SSO stands for Single Sign-On. It’s a method used to authenticate users once and allow them to access multiple applications without re-authenticating.
• OAuth 2.0, Open ID Connect, SAML are some of the common protcols used
• Example - You you login to google account, you can access various services like gmail, youtube, google drive etc.
• Key Components
  • Identity Provider (IdP) - They are responsible for authenticating the users and provide identity information to service provider.
  • Service Provider - They rely on identity providers to authenticate users
• Steps
  • The user requests for a resource from service provider.
  • It redirects the user to identity provider.
  • Once authenticated, the IdP issues a token (SAML assertion or JWT)
  • The service provider validates the token received from IdP.
  • The service provider grants access to the user.
• Pros
  • Simplifies user experience by eliminating the need to log in separately for each application and reducing password fatigue
• Cons
  • Single point of failure. If IdP is compromised, all connected services are at risk.

SAML

• SAML stands for Security Assertion Markup Language. It’s an XML based open standard for transferring identity data between Identity Provider and Service Provider.
• SAML 2.0 is the latest version of it which was released in March 2005.
• Key Components
  • Identity Provider (IdP) - performs authentication and passes the user’s profile information and authorization level to service provider.
  • Service Provider - uses the help of identity provider to authenticate and gives the user access to the resource.
• Steps
  • User tries to login to the application (service provider)
  • The application generates a SAML request and redirects the user (via browser) to the IdP.
  • The browser sends the SAML request to the IdP.
  • The IdP parses the request, authenticates the user, and generates a SAML response.
  • The SAML response is returned to the user’s browser.
  • The browser forwards the response to the Service Provider.
  • If the response is verified successfully, the user is logged in and granted access to the protected resource.
• What is SAML assertion?
  • It is the message that 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.
• Pros
  • Single sign-on (SSO) across multiple applications
  • Centralized authentication and security policies
  • Reduced password fatigue for users
  • Federated identity support
• Cons
  • Not well-suited for mobile or desktop apps
  • It’s complex, hard to debug and has limited flexibility

MFA

• MFA (Multi-Factor Authentication) is a security method that requires users to provide two or more verification factors to verify their identity when logging into an app or service.
• The main goal is to add additional layers of security beyond just a password to improve security.
• Factors in MFA
  • Something you know - password, PIN, security questions
  • Something you have - phone, hardware token, certificates
  • Something you are - biometrics like fingerprint or facial recognition
• Why MFA is important
  • Improves security
  • Compliance - often required for regulations like GDPR, HIPAA, or PCI-DSS.

LDAP

• LDAP stands for Lightweight Directory Access Protocol. It’s a vendor neutral protocol used to access and manage directory information services over a network.

References

• OWASP Authentication Cheat Sheet - https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

To be added

• LDAP
• Kerberos
• Federated Identity
• NTLM
• Active Directory
• RADIUS
• TACACS+
• IAM
• Step-up authentication
• Certificate based authentication
• How do Authenticator apps work
• How do hardware tokens work
• Knowledge based authentication
• Risk-based authentication
• Federated Identity
• IDaaS
• Identity Lifecycle Management
• Authnetication vs Authorization
• RBAC, ABAC
• Principle of Least Privilege
• Zero Trust Authentication
• Types of Password Attacks
• Passwordless Authentication
• Passkey
• HMAC
• FIDO2/WebAuthn
• X.509 Certificates