Zero Trust Identity Architecture and Authentication Flows
Zero Trust assumes hostility at all network boundaries, mandating explicit verification of identity and device context for every access request. This reference details the underlying mechanisms of primary identity federations and token validations.
OIDC (OpenID Connect) and OAuth2 Flows
OIDC is an identity layer built on top of the OAuth 2.0 protocol. The Authorization Code Flow (often with PKCE) is the gold standard for secure authentication.
- Authorization Request: The client redirects the user-agent to the authorization server (
/authorize) with response_type=code, a client_id, redirect_uri, scope=openid, and state/nonce/code_challenge.
- Authentication & Consent: The user authenticates. The server validates the credentials and requests consent if necessary.
- Authorization Response: The server redirects the user-agent back to the
redirect_uri with an authorization code and the state parameter for CSRF mitigation.
- Token Request: The client authenticates to the token endpoint (
/token), exchanging the code and code_verifier (PKCE) for an ID Token (JWT) and an Access Token.
JWT Signature Validation (RS256 vs HS256)
JWTs (JSON Web Tokens) encapsulate claims in a compact, URL-safe format. Validation of the signature is paramount to prevent token forgery.
- HS256 (HMAC with SHA-256): Symmetric signing. The Identity Provider (IdP) and the Resource Server (RS) share the same secret key. Risk: If the RS is compromised, the shared secret is exposed, allowing the attacker to forge JWTs. Suitable only for internal, tightly-coupled microservices.
- RS256 (RSA Signature with SHA-256): Asymmetric signing. The IdP signs the JWT with its private key. The RS validates the signature using the IdP's public key (retrieved via JWKS - JSON Web Key Set). Benefit: The RS only holds the public key; compromise does not lead to token forgery capabilities.
Validation Steps:
- Format: Ensure the token is three base64url-encoded strings separated by dots.
- Header Analysis: Decode the header to verify the
alg (algorithm) is expected (e.g., preventing algorithm substitution attacks where alg is changed from RS256 to HS256, forcing the RS to use the public key as a symmetric HMAC secret).
- Signature Verification: Recompute the signature over the
Header.Payload string using the specified algorithm and appropriate key, then strictly compare it against the signature appended to the token.
- Claim Validation: Verify
exp (expiration), iss (issuer), and aud (audience).
SAML (Security Assertion Markup Language) Mechanics
SAML relies on XML and SOAP/HTTP POST bindings. It is heavily utilized in legacy enterprise SSO.
- SP-Initiated Flow: The Service Provider (SP) generates an
<AuthnRequest>, signs it, deflates it, base64 encodes it, and redirects the user to the IdP.
- Authentication: The IdP authenticates the user.
- SAML Response: The IdP constructs a
<samlp:Response> containing <saml:Assertion> elements (Attributes, Authentication context). The assertion (and often the entire response) is digitally signed (XML Signature) using the IdP's private key.
- Assertion Consumer Service (ACS): The IdP POSTs the response to the SP's ACS URL. The SP validates the XML signature using the IdP's certificate and processes the assertions.
Architecture Mapping
%%{init: {"theme": "default", "flowchart": {"useMaxWidth": true}}}%%
flowchart TD
User([User Agent]) -->|1. Request Access| RP[Relying Party / Client]
RP -->|2. Redirect to IdP| IdP[Identity Provider]
User -->|3. Authenticate| IdP
IdP -->|4. Auth Code| RP
RP -->|5. Token Exchange| IdP
IdP -->|6. ID Token + Access Token| RP
RP -->|7. API Request + JWT| RS[Resource Server]
RS -->|8. Fetch JWKS| JWKS[IdP JWKS Endpoint]
JWKS -->|9. Public Key| RS
RS -->|10. Validate RS256 Signature| RS
RS -->|11. Resource Response| RP
style IdP fill:#f9f,stroke:#333,stroke-width:2px
style RS fill:#bbf,stroke:#333,stroke-width:2px
style RP fill:#bfb,stroke:#333,stroke-width:2px
1---2name: zero-trust-identity3description: Advanced Zero Trust Identity, OIDC/SAML Mechanics, and JWT Validation4---56# Zero Trust Identity Architecture and Authentication Flows78Zero Trust assumes hostility at all network boundaries, mandating explicit verification of identity and device context for every access request. This reference details the underlying mechanisms of primary identity federations and token validations.910## OIDC (OpenID Connect) and OAuth2 Flows1112OIDC is an identity layer built on top of the OAuth 2.0 protocol. The Authorization Code Flow (often with PKCE) is the gold standard for secure authentication.13141. **Authorization Request**: The client redirects the user-agent to the authorization server (`/authorize`) with `response_type=code`, a `client_id`, `redirect_uri`, `scope=openid`, and `state`/`nonce`/`code_challenge`.152. **Authentication & Consent**: The user authenticates. The server validates the credentials and requests consent if necessary.163. **Authorization Response**: The server redirects the user-agent back to the `redirect_uri` with an authorization `code` and the `state` parameter for CSRF mitigation.174. **Token Request**: The client authenticates to the token endpoint (`/token`), exchanging the `code` and `code_verifier` (PKCE) for an ID Token (JWT) and an Access Token.1819## JWT Signature Validation (RS256 vs HS256)2021JWTs (JSON Web Tokens) encapsulate claims in a compact, URL-safe format. Validation of the signature is paramount to prevent token forgery.2223* **HS256 (HMAC with SHA-256)**: Symmetric signing. The Identity Provider (IdP) and the Resource Server (RS) share the same secret key. **Risk**: If the RS is compromised, the shared secret is exposed, allowing the attacker to forge JWTs. Suitable only for internal, tightly-coupled microservices.24* **RS256 (RSA Signature with SHA-256)**: Asymmetric signing. The IdP signs the JWT with its private key. The RS validates the signature using the IdP's public key (retrieved via JWKS - JSON Web Key Set). **Benefit**: The RS only holds the public key; compromise does not lead to token forgery capabilities.2526### Validation Steps:271. **Format**: Ensure the token is three base64url-encoded strings separated by dots.282. **Header Analysis**: Decode the header to verify the `alg` (algorithm) is expected (e.g., preventing algorithm substitution attacks where `alg` is changed from RS256 to HS256, forcing the RS to use the public key as a symmetric HMAC secret).293. **Signature Verification**: Recompute the signature over the `Header.Payload` string using the specified algorithm and appropriate key, then strictly compare it against the signature appended to the token.304. **Claim Validation**: Verify `exp` (expiration), `iss` (issuer), and `aud` (audience).3132## SAML (Security Assertion Markup Language) Mechanics3334SAML relies on XML and SOAP/HTTP POST bindings. It is heavily utilized in legacy enterprise SSO.35361. **SP-Initiated Flow**: The Service Provider (SP) generates an `<AuthnRequest>`, signs it, deflates it, base64 encodes it, and redirects the user to the IdP.372. **Authentication**: The IdP authenticates the user.383. **SAML Response**: The IdP constructs a `<samlp:Response>` containing `<saml:Assertion>` elements (Attributes, Authentication context). The assertion (and often the entire response) is digitally signed (XML Signature) using the IdP's private key.394. **Assertion Consumer Service (ACS)**: The IdP POSTs the response to the SP's ACS URL. The SP validates the XML signature using the IdP's certificate and processes the assertions.4041## Architecture Mapping4243```mermaid44%%{init: {"theme": "default", "flowchart": {"useMaxWidth": true}}}%%45flowchart TD46 User([User Agent]) -->|1. Request Access| RP[Relying Party / Client]47 RP -->|2. Redirect to IdP| IdP[Identity Provider]48 User -->|3. Authenticate| IdP49 IdP -->|4. Auth Code| RP50 RP -->|5. Token Exchange| IdP51 IdP -->|6. ID Token + Access Token| RP52 RP -->|7. API Request + JWT| RS[Resource Server]53 RS -->|8. Fetch JWKS| JWKS[IdP JWKS Endpoint]54 JWKS -->|9. Public Key| RS55 RS -->|10. Validate RS256 Signature| RS56 RS -->|11. Resource Response| RP57 58 style IdP fill:#f9f,stroke:#333,stroke-width:2px59 style RS fill:#bbf,stroke:#333,stroke-width:2px60 style RP fill:#bfb,stroke:#333,stroke-width:2px61```