Understanding AuthN vs AuthZ: Decoding the SAML, OAuth2.0, and OpenID Connect Trilogy

Overview

#

Identity and Access Management is one of the important aspect in cloud native platforms. Its not only for end users but for workloads and services that need to interact with each other and with cloud APIs. As microservices scale across clusters and accounts, traditional methods of embedding static credentials or reusing node-level IAM roles fall short — they’re hard to manage, rotate, and audit.

This blog breaks down the core authentication and authorization frameworks that helps secure identity on the web

• SAML (legacy XML-based federation)
• OAuth 2.0 (delegated authorization)
• OpenID Connect (OIDC) (modern identity layer built on OAuth 2.0)
  

By the end of this blog, you’ll understand:

• The fundamentals of AuthN (authentication) and AuthZ (authorization).
• The key differences between SAML, OAuth2.0, and OIDC.
• The role of ID Tokens, Access Tokens, and Claims.
• How OpenID Connect and IRSA in EKS.
• And how to securely configure pods to assume IAM roles without secrets.

AuthN and AuthZ

#

Authentication (authn):

#

Authentication is the process of verifying that an actor (user, service, or machine) is truly who they claim to be. It’s the front gate of any secure system, where identity is proven.

Some of the common authN:

• Passwords (knowledge)
• MFA / OTP (possession)
• Biometrics (inherence)
• Certificates / Tokens (cryptographic proof)
• OIDC tokens for workloads (non-human identity)

Once successful, the system issues a credential or token that represents your identity.

• In OIDC: an ID Token (JWT)
• In SAML: a SAML Assertion
• In traditional apps: a session cookie

That token becomes the proof of identity that downstream systems can verify.

Authorization (authz):

#

Authorization kicks in after authentication. Now that the system knows who you are, it decides what you’re allowed to do. It evaluates policies, roles, scopes, or attributes to enforce permissions:

• Role-Based Access Control (RBAC) - e.g. admin, viewer
• Attribute-Based Access Control (ABAC) - e.g. based on context like department, region, time
• Relationship-Based Access Control (ReBAC) - e.g. “user owns this resource”

Typical mechanisms:

• Access Tokens (OAuth 2.0) → define scopes like read, write
• Policy engines → OPA/Rego, AWS IAM policies, Cedar
• Context-aware decisions → IP, device, risk signals

The Core Actors

#

No matter whether its SAML, OAuth 2.0, or OIDC, the actors remains consistent, only the terminology changes.

1. The Principal (Subject)

The Principal also called the Subject is the entity trying to access a system.

It could be:

• A human user (logging into a dashboard)
• A service or workload (a pod calling an API or service)
• A machine identity (CI/CD runner)

Every authentication flow exists to verify this actor’s identity.

2. The Identity Provider (IdP) - Authentication Layer

The Identity Provider (IdP) is the source of truth for identity. It verifies credentials, authenticates the principal, and issues tokens or assertions representing identity.

Analogy - IdP is like the security guard at the gate, checking credentials and stamping a verified badge.

Common examples:

• Corporate IdPs: Azure AD, Okta, Ping Identity, Keycloak
• Cloud IdPs: AWS Cognito, Google Identity, Auth0
• Federated IdPs: LinkedIn, GitHub, Google (Sign-In with Google)

Note:

• In OIDC, the IdP is also called the OpenID Provider (OP).
• In SAML, it’s simply the IdP.

3. The Relying Party (RP) / Service Provider (SP)

Once identity is proven, the Relying Party (RP) or Service Provider (SP) is the application or service that consumes the identity to grant access.

• In OIDC, it’s called the Relying Party (RP)
• In SAML, it’s the Service Provider (SP)

These systems trust the IdP to handle authentication, and they focus on business logic and enforces authorization decisions that comes from authorization server

Examples:

• Jira relying on your corporate IdP for authentication.
• An internal application trusting Google Identity via OIDC
• A microservice verifying a JWT before processing an API request

Responsibility:

• Validates tokens or assertions
• Establishes a session (cookie / access token)
• Enforces AuthZ (policies, roles, scopes)

4. The Resource Server (API Layer)

In OAuth 2.0 & OIDC ecosystems, the Resource Server is the API that protects actual data or actions. It validates access tokens to ensure requests are authorized.

Examples:

• AWS S3 validating IAM-signed requests.
  • S3 acts as the Resource Server. It trusts AWS STS (the Identity Provider) to authenticate callers and issues temporary IAM credentials
• A backend service enforcing scope-based access using AWS cognito.
  • The backend API acts as the Resource Server. It relies on AWS Cognito to authenticate users and issue JWT access tokens. When a request comes in, the service verifies the token’s signature and checks its scopes (e.g. read, write) to determine what operations the caller is permitted to perform.

5. The Authorization Server (AS) - Authorization Layer

In OAuth 2.0, the Authorization Server is the issuer of tokens and the enforcer of consent and scopes.

Responsibility:

• Handles OAuth grant flows (Authorization Code, Client Credentials, etc.)
• Issues Access Tokens and optionally Refresh Tokens
• Manages consent (“Allow this app to read your data?”)

6. The Client Application (Requester)

The Client is the application requesting tokens on behalf of the user or itself.

It could be:

• A web app (frontend)
• A mobile app (iOS/Android)
• A service (backend microservice using Client Credentials)

Clients must register with the IdP / AS and receive a Client ID, Client Secret to identify themselves.

SAML v/s OpenID v/s OAuth2.0 Trilogy

#

SAML (Security Assertion Markup Language)

#

SAML is an XML-based open standard that allows Identity Providers (IdPs) to authenticate users and pass their identity and attributes to Service Providers (SPs). It’s used for SSO (Single Sign-On) users log in once (e.g. via the corporate identity) and can access multiple apps without re-entering credentials.

SAML Assertion

#

A SAML Assertion is an XML document issued by the IdP, digitally signed (and sometimes encrypted) with an X.509 certificate.

It contains statements about the user, such as:

• Authentication Statement: proves the user logged in
• Attribute Statement: provides user details (email, groups, roles)
• Authorization Decision Statement: (optional) access rights

OAuth2.0

#

OAuth 2.0 is an authorization framework (not a protocol for authentication). It defines how a client can obtain and use access tokens to call protected APIs — where the user or system owns the data but delegates access to another app.

How does OAuth2.0 work

#

Before OAuth 2.0, apps needed passwords to call an API on your behalf it was risky and brittle.

OAuth 2.0 introduces a token-based model:

• The user authenticates (outside OAuth’s scope)
• The user consents to the requested access
• The Authorization Server issues tokens
• The Client uses tokens to access APIs

What does it solve:

• Passwords are never shared with third-party apps
• Access can be scoped, time-bound, and revocable

OAuth 2.0 is all about authorization — granting limited access to resources — it was never designed to authenticate users.

OpenID Connect

#

OpenID Connect (OIDC) is an authentication and identity federation protocol built on top of OAuth 2.0. It uses the same flows, tokens, and endpoints — but adds a standardized identity layer.

OAuth 2.0 tells you what you can do; OIDC tells you who you are.

OAuth 2.0 v/s OIDC

#

OAuth 2.0 alone gives you Access Tokens, but those tokens:

• Don’t guarantee who is behind them.
• Might not even represent a human (could be a service).
• Were never intended for login or session creation.

OIDC provides:

• Verified identity claims (subject, email, name).
• Standardized login flows (Authorization Code + PKCE).
• JWT-based ID Tokens signed by the IdP.

Relationship

Example of an ID Token (Decoded JWT)

#

{
  "iss": "https://auth.company.com",
  "sub": "d8f2a1b3",
  "aud": "client-123",
  "email": "vinay@thequietkernel.com",
  "name": "Vinay V",
  "iat": 1735919271,
  "exp": 1735922871
}

iss — Issuer

• The Identity Provider (IdP) that issued this token.
  • A URL identifier pointing to the issuing IdP.
  • Helps ensure your app only accepts tokens from trusted sources.
  • Common values:
    • https://accounts.google.com
    • https://login.microsoftonline.com/{tenantId}/v2.0
    • https://cognito-idp.ap-south-1.amazonaws.com/ap-south-1_abc123

When your app (Relying Party) validates the ID Token, it must check:

sub — Subject

• The unique identifier for the authenticated user. Represents the principal (user) in the IdP.
• Guarantees uniqueness of user identity across sessions and tokens.

aud — Audience

• The intended recipient of the token (usually the Client ID). Tells you which application this token was issued for.
• Should match your OIDC client ID.
• Tokens with mismatched aud should be rejected.

iat / exp — Issued At / Expiry

• When the token was issued and when it expires.
  • iat (Issued At) — Unix timestamp seconds since epoch
  • exp (Expiration Time) — timestamp when token becomes invalid

How does OpenID work underneath

#

OpenID Connect (OIDC) with EKS

#

In traditional Kubernetes setups before OIDC/IRSA, applications running inside pods that needs to connect to AWS services like S3, DynamoDB, or Secrets Manager etc..

1. Had to rely on manual credential injections via configMap and environment variables.

env:
  - name: AWS_ACCESS_KEY_ID
    value: AKIA...
  - name: AWS_SECRET_ACCESS_KEY
    valueFrom:
      secretKeyRef:
        name: aws-creds
        key: secret-access-key

2. Using Node IAM Roles (Without OIDC)

EKS worker nodes (EC2) can have instance IAM roles.Pods running on that node would inherit the node’s credentials automatically through the EC2 metadata service.

Read more about this - here

To solve this, Amazon EKS integrates OpenID Connect (OIDC) with AWS IAM, enabling Workload Identity through a mechanism called IAM Roles for Service Accounts (IRSA).

How does it work

#

OIDC turns Kubernetes Service Accounts into federated identities that AWS can trust — no static credentials, no secret management.Every pod in Kubernetes runs under a Service Account. With OIDC enabled:

• Each Service Account is mapped to an IAM Role.
• The cluster’s OIDC provider issues signed ID tokens representing the pod’s identity.
• AWS STS exchanges these tokens for short-lived IAM credentials.
• Pods can then call AWS APIs securely.

With this setup authentication is handled by the OIDC token issued by the cluster and the authorization is enforced by IAM role policies.

Working example of OpenID connect with EKS cluster

#

1. To enable OIDC for the cluster:

eksctl utils associate-iam-oidc-provider \
  --region ap-south-1 \
  --cluster sandbox-cluster \
  --approve

• EKS registers an OIDC issuer URL (e.g.https://oidc.eks.ap-south-1.amazonaws.com/id/818DE33AC501E25CBA0D9F46F922E90F)
• This acts as the OpenID Provider (IdP) exposing: .well-known/openid-configuration
• /keys JWKS endpoint (for signature validation)

2. IAM Role with Trust Policy as below:

This is done to ensure - AWS IAM is configured to trust tokens from this OIDC provider only for specific Service Accounts:

Add the below in the trust policy section of version-service-role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::720736521509:oidc-provider/oidc.eks.ap-south-1.amazonaws.com/id/818DE33AC501E25CBA0D9F46F922E90F"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
            "oidc.eks.ap-south-1.amazonaws.com/id/818DE33AC501E25CBA0D9F46F922E90F:aud": "sts.amazonaws.com",
            "oidc.eks.ap-south-1.amazonaws.com/id/818DE33AC501E25CBA0D9F46F922E90F:sub": "system:serviceaccount:version-service:version-service-sa"
        }
      }
    }
  ]
}

Note: The sub claim in the OIDC token must match system:serviceaccount::.

3. Annotate the service account:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: version-service-sa
  namespace: version-service
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::720736521509:role/version-service-role

The following happens when pod uses the above service account.

• A web identity token file is mounted /var/run/secrets/eks.amazonaws.com/serviceaccount/token and the file contains the jwt token (oidc token) - issued by the cluster’s OIDC provider.
• It injects an OIDC web identity token, and the AWS SDK uses that token + env variables to automatically assume the IAM role via sts:AssumeRoleWithWebIdentity (ensure that this permission is set in the IAM policy)
• Here are the list of environment variable that gets added in the node.

Note: You will not see AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY — because those are not static. They’re dynamically fetched by the AWS SDK using the OIDC token, using STS as explained below.

4. Pod and service commnucation.

Inside the pod, the AWS SDK automatically performs: AssumeRoleWithWebIdentity to AWS STS with the OIDC token obtained from the token file.

AWS STS validates the following:

• Signature (via JWKS)
• Issuer (iss)
• Audience (aud = sts.amazonaws.com)
• Subject (sub)

If the above metadata is valid STS returns a temporary credentials that are short lived AWS credentials, set as an environment variable for pod.

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN

which can be used by aws sdk or aws-cli to securely call AWS API’s and services.

OIDC Token (Decoded)

{
  "iss": "https://oidc.eks.ap-south-1.amazonaws.com/id/818DE33AC501E25CBA0D9F46F922E90F",
  "sub": "system:serviceaccount:version-service:version-service-sa",
  "aud": "sts.amazonaws.com",
  "kubernetes.io": {
    "namespace": "version-service",
    "serviceaccount": {"name": "version-service-sa"},
    "pod": {"name": "version-service-233nsddcs", "uid": "deffkhvvsccxas-4556788"}
  },
  "exp": 1735922871
}

Further Reads:

#

• More about OpenID connect - https://openid.net/developers/how-connect-works/
• OpenID in AWS : https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html
• OpenID with EKS : https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html
• Bring your own OIDC provider - https://docs.aws.amazon.com/eks/latest/userguide/authenticate-oidc-identity-provider.html
• IRSA - https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html