Lesson Eighteen

Authentication Systems, Federation, SSO, and Identity Protocols

SierraTec Secure CISSP Certification Preparation Course

Lesson Overview

Lesson Seventeen established the foundational Identity and Access Management sequence:

IDENTIFY

   ↓

AUTHENTICATE

   ↓

AUTHORIZE

   ↓

ACCOUNT

   ↓

REVIEW

   ↓

TERMINATE

Lesson Eighteen examines the technologies that make those functions possible across enterprise, cloud, network, application, and federated environments.

A modern organization may simultaneously use:

• Active Directory;

• LDAP;

• Kerberos;

• RADIUS;

• TACACS+;

• certificates;

• smart cards;

• FIDO/WebAuthn;

• passkeys;

• SAML;

• OAuth 2.0;

• OpenID Connect;

• SCIM;

• cloud identity providers.

The challenge is not simply knowing the protocol names.

The CISSP professional must understand:

What problem does each technology solve, where does trust reside, what is being authenticated or authorized, what credential or assertion is exchanged, and what can go wrong?

The current CISSP Examination Outline places this material primarily under:

• 5.2 — Design identification and authentication strategy

• 5.3 — Federated identity with a third-party service

• 5.6 — Implement authentication systems.

Current Objective 5.2 explicitly includes:

• groups and roles;

• AAA;

• MFA;

• passwordless authentication;

• session management;

• identity registration and proofing;

• Federated Identity Management;

• credential-management systems;

• SSO;

• Just-In-Time access.

Objective 5.3 explicitly requires federated identity across:

• on-premises;

• cloud;

• hybrid environments.

Objective 5.6 is deliberately broad:

Implement authentication systems.

The named protocols taught in this lesson therefore support that objective rather than representing an ISC2-mandated protocol list.

The central Lesson Eighteen question is:

How do authentication, directory, federation, SSO, and delegated-authorization technologies establish and transfer trust across users, devices, applications, network equipment, cloud services, and organizational boundaries?

CISSP Exam Objective Alignment

Learning Objectives

After completing this lesson, you should be able to:

1. Explain centralized authentication.

2. Explain decentralized authentication.

3. Define a directory service.

4. Explain LDAP.

5. Explain why LDAP is not identical to Active Directory.

6. Explain directory objects and attributes.

7. Explain LDAP distinguished names conceptually.

8. Explain secure LDAP communication.

9. Describe Active Directory Domain Services at a CISSP level.

10. Explain domains, forests, and domain controllers conceptually.

11. Explain Kerberos.

12. Define a Kerberos principal.

13. Define a realm.

14. Explain the Key Distribution Center.

15. Explain the Authentication Server.

16. Explain the Ticket Granting Server.

17. Explain the Ticket Granting Ticket.

18. Explain service tickets.

19. Describe the Kerberos authentication flow.

20. Explain why Kerberos depends on protected KDC infrastructure.

21. Explain Kerberos time dependence.

22. Explain pass-the-ticket conceptually.

23. Explain forged-ticket risk conceptually.

24. Explain NTLM at a high level.

25. Define AAA.

26. Explain RADIUS.

27. Explain TACACS+.

28. Compare RADIUS and TACACS+.

29. Explain certificate-based authentication.

30. Explain smart-card authentication.

31. Explain public-key authentication.

32. Explain FIDO2/WebAuthn conceptually.

33. Explain passkeys.

34. Explain relying-party-scoped public-key credentials.

35. Define identity federation.

36. Explain Identity Providers.

37. Explain relying parties.

38. Explain Service Providers.

39. Define assertions.

40. Explain federated trust.

41. Explain SAML.

42. Explain SAML assertions.

43. Explain SP-initiated SAML SSO conceptually.

44. Explain IdP-initiated SAML SSO conceptually.

45. Explain OAuth 2.0.

46. Explain why OAuth is fundamentally an authorization framework.

47. Identify OAuth roles.

48. Explain access tokens.

49. Explain refresh tokens.

50. Explain scopes.

51. Explain authorization-code flow conceptually.

52. Explain PKCE at a high level.

53. Explain OpenID Connect.

54. Distinguish OAuth from OIDC.

55. Distinguish access tokens from ID tokens.

56. Explain JWTs conceptually.

57. Explain why a JWT is not automatically encrypted.

58. Explain SSO security considerations.

59. Explain SCIM.

60. Explain how SCIM differs from SAML/OIDC.

61. Explain on-premises federation.

62. Explain cloud federation.

63. Explain hybrid identity.

64. Explain identity brokers.

65. Identify common federation attack scenarios.

66. Apply CISSP FIRST/BEST/MOST reasoning to authentication questions.

Part I — Authentication Architecture

1. Authentication Is a Trust Decision

Authentication asks:

Can this subject demonstrate that it controls the authenticator associated with the claimed identity?

The result may then be used for:

• local access;

• network access;

• application SSO;

• federation;

• privileged administration.

2. Authentication Architecture

SUBJECT

   │

   ▼

IDENTITY CLAIM

   │

   ▼

AUTHENTICATION SYSTEM

   │

   ▼

VALIDATE AUTHENTICATOR

   │

   ▼

AUTHENTICATION RESULT

   │

   ▼

AUTHORIZATION SYSTEM

Part II — Centralized Authentication

3. Centralized Authentication

A centralized authentication architecture uses a central identity or authentication service for multiple systems.

               IDENTITY SYSTEM

                     │

          ┌──────────┼──────────┐

          ▼          ▼          ▼

       APP A       APP B      NETWORK

4. Advantages

Centralization can improve:

• policy consistency;

• credential management;

• auditing;

• account termination;

• authentication enforcement.

5. Concentration Risk

Centralization also creates a high-value dependency.

If the centralized identity system is compromised:

Many downstream systems may be affected.

Therefore central identity infrastructure requires exceptional:

• availability;

• protection;

• monitoring;

• recovery planning.

Part III — Decentralized Authentication

6. Decentralized Model

In a decentralized model, separate systems maintain separate authentication stores.

APP A → USER DATABASE A



APP B → USER DATABASE B



APP C → USER DATABASE C

7. Risks

This may create:

• duplicated accounts;

• password reuse;

• inconsistent policies;

• difficult offboarding;

• administrative overhead.

Part IV — Directory Services

8. What Is a Directory?

A directory stores structured information about entities such as:

• users;

• groups;

• computers;

• services;

• organizational units.

9. Directory Example

ORGANIZATION

   │

   ├── USERS

   │     ├── Alice

   │     └── Bob

   │

   ├── GROUPS

   │     ├── Finance

   │     └── Security

   │

   └── COMPUTERS

         ├── PC01

         └── SRV01

Part V — LDAP

10. Lightweight Directory Access Protocol

LDAP is an application protocol used to access and interact with directory services.

The IETF's LDAP specification describes LDAP as providing access to distributed directory services consistent with X.500 directory models.

11. LDAP Is a Protocol

Important CISSP distinction:

LDAP is a protocol.

It is not the same thing as:

Active Directory.

Active Directory is a directory-service implementation that supports LDAP among other technologies.

12. LDAP Operations

Conceptually, LDAP clients may perform operations such as:

• search;

• bind;

• add;

• modify;

• delete.

Part VI — LDAP Bind

13. Bind

An LDAP bind establishes an authentication context between the client and directory server.

Depending on configuration, authentication may use different mechanisms.

14. Directory Lookup

Example:

APPLICATION

    │

    ▼

LDAP QUERY

    │

    ▼

DIRECTORY

    │

    ▼

USER / GROUP ATTRIBUTES

Part VII — Distinguished Names

15. Distinguished Name

LDAP directory objects can be identified through hierarchical Distinguished Names.

Conceptually:

CN=Alice,

OU=Finance,

DC=example,

DC=com

The exact syntax matters less for CISSP than recognizing the hierarchical directory concept.

Part VIII — LDAP Security

16. Plain LDAP Communication

Directory traffic may contain:

• authentication exchanges;

• identity attributes;

• sensitive organizational information.

Therefore unprotected directory communication can create risk.

Microsoft's current AD DS guidance notes that ordinary LDAP commonly uses port 389 and that LDAP over TLS commonly uses port 636; it also describes LDAP signing and channel binding as protections against tampering and session attacks in AD environments.

17. CISSP Principle

Do not memorize:

“389 bad, 636 good”

as an absolute rule.

LDAP security can also involve mechanisms such as:

• signing;

• SASL;

• StartTLS;

• other secured bindings.

The important principle is:

Protect authentication and directory communication appropriately.

Part IX — Active Directory

18. Active Directory Domain Services

Microsoft Active Directory Domain Services is an enterprise directory system providing identity, directory, domain-join, group, policy, and authentication functionality.

Microsoft documents AD-related domain services as supporting LDAP, Kerberos, NTLM authentication, domain join, and Group Policy capabilities.

19. Active Directory Conceptual Structure

FOREST

   │

   ├── DOMAIN A

   │      ├── Users

   │      ├── Groups

   │      └── Computers

   │

   └── DOMAIN B

          ├── Users

          ├── Groups

          └── Computers

Part X — Domain Controller

20. Domain Controller

A domain controller provides domain identity and directory services.

Because it supports authentication and directory operations:

A domain controller is a high-value security asset.

Part XI — Authentication Protocols in AD

21. Kerberos and NTLM

Modern Windows domain environments commonly rely on Kerberos, with NTLM retained for some compatibility scenarios.

For CISSP purposes:

Kerberos is the principal ticket-based authentication model to understand deeply.

Part XII — Kerberos

22. What Is Kerberos?

Kerberos is a trusted third-party, ticket-based network authentication system.

RFC 4120 describes Kerberos V5 as verifying principals across an unprotected network using a trusted third-party authentication service and shared-secret cryptography.

23. Primary Objective

Kerberos allows users and services to authenticate without repeatedly transmitting the user's password to every service.

Part XIII — Kerberos Terminology

24. Principal

A principal is an identity known to Kerberos.

Examples:

• user;

• service.

25. Realm

A realm represents a Kerberos administrative authentication domain.

26. Key Distribution Center

The Key Distribution Center, or KDC, is the trusted Kerberos service.

Conceptually:

KDC

 ├── AUTHENTICATION SERVER

 └── TICKET GRANTING SERVER

Part XIV — Authentication Server

27. AS

The Authentication Server authenticates the principal sufficiently to issue the credentials needed to begin the Kerberos ticket process.

The client ultimately receives a:

Ticket Granting Ticket

Part XV — Ticket Granting Ticket

28. TGT

The Ticket Granting Ticket allows a user to request additional service tickets without repeatedly presenting the original password to each service.

USER AUTHENTICATES

       │

       ▼

KDC / AS

       │

       ▼

TGT

Part XVI — Ticket Granting Server

29. TGS

The Ticket Granting Server accepts a valid TGT and issues tickets for specific services.

Part XVII — Service Ticket

30. Service Ticket

A service ticket allows a client to authenticate to a particular service.

Examples:

• file service;

• database service;

• application service.

Part XVIII — Kerberos Flow

31. Complete Simplified Flow

USER / CLIENT

     │

     │ 1. Authentication request

     ▼

AUTHENTICATION SERVER

     │

     │ 2. TGT

     ▼

CLIENT

     │

     │ 3. TGT + service request

     ▼

TICKET GRANTING SERVER

     │

     │ 4. Service ticket

     ▼

CLIENT

     │

     │ 5. Service ticket

     ▼

APPLICATION / SERVER

     │

     ▼

ACCESS IF AUTHORIZED

32. The Password Is Not Sent to Every Service

This is a major benefit.

The system instead relies on:

• tickets;

• session keys;

• trusted KDC infrastructure.

Part XIX — Kerberos Security Dependency

33. KDC Is Highly Critical

If the KDC or critical KDC keys are compromised:

authentication trust can be severely affected across the environment.

34. Protect Kerberos Infrastructure

Protect:

• domain controllers;

• KDC keys;

• privileged accounts;

• time infrastructure;

• service-account secrets.

Part XX — Kerberos and Time

35. Time Matters

Kerberos authenticators and tickets rely partly on time-based validity.

Large clock differences can:

• cause authentication failures;

• undermine replay protections.

36. Time Synchronization

Therefore reliable time synchronization is operationally important.

CLIENT TIME

     ≈

KDC TIME

     ≈

SERVER TIME

Part XXI — Kerberos Attack Concepts

37. Pass-the-Ticket

An attacker who steals a usable Kerberos ticket may attempt to reuse it without knowing the original user's password.

38. Ticket Forgery

Compromise of critical Kerberos secrets can enable forged-ticket attacks.

At CISSP level, remember:

Protecting authentication-system cryptographic secrets is more important than memorizing attack-tool commands.

39. Kerberoasting Concept

Attackers may request service tickets associated with service accounts and attempt offline analysis against weak service-account credentials.

The CISSP response focuses on:

• strong managed service credentials;

• least privilege;

• monitoring;

• modern service identities.

Part XXII — NTLM

40. NTLM Concept

NTLM is a challenge-response authentication technology retained largely for compatibility in Microsoft environments.

For CISSP:

Treat NTLM as a legacy-compatible authentication mechanism rather than the preferred modern domain-authentication architecture when Kerberos can be used appropriately.

Part XXIII — AAA Revisited

41. Authentication, Authorization, Accounting

AUTHENTICATION

Who are you?

      │

      ▼

AUTHORIZATION

What may you do?

      │

      ▼

ACCOUNTING

What did you do?

Network-access systems commonly centralize these functions.

Part XXIV — RADIUS

42. Remote Authentication Dial-In User Service

RADIUS is commonly used for centralized network-access authentication and related authorization/configuration.

RFC 2865 describes RADIUS as carrying authentication, authorization, and configuration information between network-access servers and a shared authentication server. The officially assigned RADIUS authentication port is UDP 1812.

43. RADIUS Architecture

USER / DEVICE

      │

      ▼

NETWORK ACCESS DEVICE

      │

      ▼

RADIUS SERVER

      │

   ┌──┴───┐

   ▼      ▼

ACCEPT   REJECT

44. Examples

RADIUS may support authentication for:

• wireless networks;

• VPNs;

• network-access infrastructure;

• 802.1X environments.

Part XXV — RADIUS Accounting

45. Accounting

RADIUS deployments commonly also use separate accounting functions to record:

• session start;

• session stop;

• usage.

For exam reasoning, associate RADIUS strongly with:

network access.

Part XXVI — Modern RADIUS Note

46. RADIUS Security Modernization

The original RADIUS protocol is old and has accumulated extensions.

In April 2025, the IETF published experimental RFC 9765 defining a RADIUS/1.1 profile for RADIUS over TLS/DTLS that removes historical MD5-based packet-authentication and obfuscation mechanisms in that transport profile.

For CISSP:

Know the role of RADIUS first; treat protocol-hardening developments as implementation context.

Part XXVII — TACACS+

47. TACACS+

TACACS+ is strongly associated with centralized administrative access to:

• routers;

• switches;

• network devices.

RFC 8907 describes TACACS+ as widely deployed for device administration and emphasizes its separation of authentication, authorization, and accounting functions.

Part XXVIII — TACACS+ Architecture

48. Example

NETWORK ADMIN

      │

      ▼

ROUTER

      │

      ▼

TACACS+ SERVER

      │

      ├── AUTHENTICATION

      ├── AUTHORIZATION

      └── ACCOUNTING

49. Command Authorization

A major advantage in network-device administration is the ability to implement fine-grained command authorization and accounting.

Example:

Administrator may be permitted to:

show configuration

but denied:

erase configuration.

Part XXIX — Current TACACS+ Security Update

50. TACACS+ over TLS 1.3

In December 2025, the IETF published RFC 9887, a Standards Track update specifying TACACS+ over TLS 1.3.

The update replaces weak legacy TACACS+ obfuscation with TLS-based confidentiality, integrity, and peer authentication.

This is an important current implementation update.

Part XXX — RADIUS Versus TACACS+

51. Comparison

52. CISSP Memory Rule

RADIUS → Network Access

TACACS+ → Network Device Administration

This is a useful exam association, not an absolute technical limitation.

Part XXXI — Certificate-Based Authentication

53. Public-Key Authentication

Instead of proving identity using a reusable password, a subject can demonstrate control of:

a private cryptographic key.

The corresponding:

public key

can be associated with the identity through a trusted certificate or registration process.

54. Certificate Authentication

SUBJECT

   │

   ▼

PRIVATE KEY

   │

   ▼

CRYPTOGRAPHIC PROOF

   │

   ▼

CERTIFICATE / PUBLIC KEY

   │

   ▼

VALIDATION

   │

   ▼

AUTHENTICATION

Part XXXII — Smart Cards

55. Smart Card

A smart card can securely hold cryptographic key material.

Authentication may combine:

• possession of the card;

• knowledge of a PIN.

56. Smart Card MFA

SMART CARD

Something you have

       +

PIN

Something you know

       =

MFA

Part XXXIII — Certificate Authentication Risks

57. Key Protection

Certificate authentication is only as trustworthy as:

• private-key protection;

• certificate validation;

• revocation;

• enrollment.

58. Lost Credential

If a smart card or private key is compromised:

• revoke the certificate;

• replace credential material;

• investigate unauthorized use.

Part XXXIV — FIDO2 and WebAuthn

59. Modern Public-Key Authentication

FIDO/WebAuthn authentication uses public-key credentials scoped to relying parties rather than reusable shared passwords.

The current WebAuthn Level 3 specification was published as a W3C Candidate Recommendation Snapshot in May 2026 and describes strong, scoped, public-key credentials created by authenticators for relying parties.

60. WebAuthn Registration

Conceptually:

USER

  │

  ▼

AUTHENTICATOR

  │

  ├── Generate private key

  │

  └── Produce public key

              │

              ▼

        RELYING PARTY

        stores public key

Part XXXV — WebAuthn Authentication

61. Authentication Ceremony

RELYING PARTY

      │

      │ Challenge

      ▼

AUTHENTICATOR

      │

      │ Signed response

      ▼

RELYING PARTY

      │

      ▼

VERIFY PUBLIC KEY

The W3C specification describes authentication as cryptographically proving control of a previously registered private key to the relying party.

Part XXXVI — Why WebAuthn Helps Against Phishing

62. Relying-Party Scope

WebAuthn credentials are scoped to a relying party.

This helps prevent a fake site from simply collecting and replaying a reusable password.

63. Password Versus Public-Key Credential

Traditional password:

USER KNOWS SECRET

        │

        ▼

SECRET SENT / PROVED

TO SERVICE

Public-key authentication:

PRIVATE KEY

STAYS PROTECTED

      │

      ▼

SIGNED PROOF

      │

      ▼

PUBLIC KEY VERIFIES

Part XXXVII — Passkeys

64. Passkeys

Passkeys are an implementation model for public-key authentication that may use platform or synchronized authenticators.

NIST SP 800-63 Revision 4 explicitly includes modern syncable authenticators in its current digital-authentication framework.

65. Exam Principle

You do not need to memorize every FIDO implementation detail.

Remember:

Passkeys replace reusable password authentication with relying-party-scoped public-key credentials.

Part XXXVIII — Identity Federation

66. What Is Federation?

Federation allows an identity authenticated in one security domain to be trusted by another independently administered service.

NIST SP 800-63C-4 describes federation as allowing a credential service provider to provide authentication and, optionally, subscriber attributes to separately administered relying parties.

67. Basic Federation

USER

  │

  ▼

IDENTITY PROVIDER

  │

  │ trusted assertion/token

  ▼

RELYING PARTY

  │

  ▼

APPLICATION

Part XXXIX — Identity Provider

68. IdP

An Identity Provider authenticates the user and provides trusted identity information to another system.

Part XL — Relying Party

69. RP

A Relying Party relies on authentication or identity information received from the federated identity infrastructure.

In some technologies the application is called:

Service Provider.

Part XLI — Trust Relationship

70. Federation Requires Trust

Before accepting an assertion, a relying party must know:

• who issued it;

• whether the issuer is trusted;

• whether it is valid;

• whether it was intended for this relying party;

• whether it has expired.

Part XLII — Assertion

71. Assertion

An assertion communicates statements about an identity.

Examples:

• user authenticated;

• user's identifier;

• group membership;

• authentication context.

Part XLIII — Federation Flow

72. Concept

USER REQUESTS APPLICATION

        │

        ▼

APPLICATION NEEDS IDENTITY

        │

        ▼

IDENTITY PROVIDER

        │

        ▼

USER AUTHENTICATES

        │

        ▼

SIGNED ASSERTION / TOKEN

        │

        ▼

APPLICATION VALIDATES

        │

        ▼

LOCAL AUTHORIZATION

Part XLIV — Authentication Versus Federation

73. Important Distinction

Authentication:

proves identity to an authentication authority.

Federation:

transfers trusted authentication/identity information between security domains.

Part XLV — SAML

74. Security Assertion Markup Language

SAML is an XML-based framework for exchanging security assertions across security domains.

OASIS describes SAML as an XML framework for exchanging authentication, attribute, and authorization-related security information between parties with established trust relationships.

75. SAML Roles

For web SSO, think:

IDENTITY PROVIDER

       │

       │ SAML assertion

       ▼

SERVICE PROVIDER

Part XLVI — SAML Assertion

76. Assertion Contents

A SAML assertion may contain statements about:

• authentication;

• attributes;

• authorization-related information.

OASIS describes authentication, attribute, and authorization statements as core SAML assertion concepts.

Part XLVII — SP-Initiated SAML

77. SP-Initiated Flow

USER

  │

  ▼

SERVICE PROVIDER

  │

  │ Redirect to IdP

  ▼

IDENTITY PROVIDER

  │

  ▼

AUTHENTICATE USER

  │

  ▼

SAML RESPONSE

  │

  ▼

SERVICE PROVIDER

  │

  ▼

APPLICATION ACCESS

Part XLVIII — IdP-Initiated SAML

78. IdP-Initiated Concept

The user begins at the identity provider and selects an application.

USER

  │

  ▼

IDENTITY PROVIDER PORTAL

  │

  ▼

SAML RESPONSE

  │

  ▼

SERVICE PROVIDER

Part XLIX — SAML Security

79. Validate Assertions

A Service Provider should validate relevant properties such as:

• digital signature;

• issuer;

• audience;

• validity conditions.

80. Replay Risk

If an attacker steals an assertion and can replay it successfully:

federation trust has failed.

Assertions should have appropriate:

• validity;

• audience restrictions;

• replay protections.

Part L — SAML Is Not the Same as LDAP

81. Remember

LDAP:

Accesses directory information.

SAML:

Exchanges security assertions, commonly for federation/SSO.

Part LI — OAuth 2.0

82. OAuth Purpose

OAuth 2.0 is fundamentally an:

Authorization Framework

RFC 6749 describes OAuth 2.0 as allowing a third-party application to obtain limited access to HTTP resources either on behalf of a resource owner or on its own behalf.

83. Critical CISSP Trap

OAuth is not fundamentally an authentication protocol.

It delegates:

authorization.

Part LII — OAuth Problem

84. Without Delegation

Suppose a calendar application wants access to a user's cloud contacts.

Bad model:

User gives calendar application their cloud-account password.

OAuth instead allows:

Limited delegated access.

Part LIII — OAuth Roles

85. Four Core Roles

RFC 6749 defines:

1. Resource Owner

2. Client

3. Authorization Server

4. Resource Server.

86. Resource Owner

The entity capable of granting access to a protected resource.

Often:

the user.

87. Client

The application requesting delegated access.

88. Authorization Server

The server that issues access tokens after appropriate authorization.

89. Resource Server

The service hosting the protected resource and accepting valid access tokens.

Part LIV — OAuth Flow

90. Simplified Architecture

RESOURCE OWNER

      │

      │ approves

      ▼

CLIENT APPLICATION

      │

      ▼

AUTHORIZATION SERVER

      │

      │ access token

      ▼

CLIENT

      │

      ▼

RESOURCE SERVER

Part LV — Access Token

91. Access Token

An access token represents authorization to access protected resources.

The client presents the token to the resource server.

92. Important Principle

An access token should be used for:

accessing authorized resources.

It should not automatically be treated as:

proof of user identity for an application login.

Part LVI — Scope

93. Scope

OAuth scopes restrict what access the token grants.

Example:

calendar.read



NOT



calendar.delete

94. Least Privilege Applies

OAuth permissions should follow:

minimum required delegated access.

Part LVII — Refresh Token

95. Refresh Token

A refresh token may allow a client to obtain new access tokens without requiring the complete original authorization process each time.

Because refresh tokens may be long-lived:

protect them carefully.

Part LVIII — Authorization Code Flow

96. Simplified Flow

USER

 │

 ▼

CLIENT

 │

 │ Redirect

 ▼

AUTHORIZATION SERVER

 │

 │ User authenticates / authorizes

 ▼

AUTHORIZATION CODE

 │

 ▼

CLIENT

 │

 │ Exchange code

 ▼

TOKEN ENDPOINT

 │

 ▼

ACCESS TOKEN

Part LIX — PKCE

97. Proof Key for Code Exchange

PKCE strengthens authorization-code flows by binding the authorization request and token exchange using a cryptographic verifier/challenge mechanism.

Current OAuth 2.0 Security Best Current Practice, RFC 9700, requires authorization servers to support PKCE and recommends secure challenge methods such as S256.

Part LX — Modern OAuth Security

98. OAuth Has Evolved

The original RFC 6749 remains foundational, but current implementations should also consider newer security best practices.

RFC 9700, published in January 2025, updates OAuth 2.0 security recommendations and addresses modern attack scenarios.

Part LXI — OpenID Connect

99. OIDC

OpenID Connect adds an:

Identity Layer

on top of OAuth 2.0.

The OpenID Foundation defines OIDC 1.0 as an identity layer on OAuth 2.0 that enables clients to verify the end user's identity based on authentication performed by an authorization server.

Part LXII — OIDC Purpose

100. OAuth Question

Can this client access this resource?

101. OIDC Question

Who is the authenticated user?

Part LXIII — OIDC Flow

102. Simplified

USER

  │

  ▼

APPLICATION

  │

  ▼

OPENID PROVIDER

  │

  ▼

AUTHENTICATE USER

  │

  ▼

ID TOKEN

  │

  ▼

APPLICATION

Part LXIV — ID Token

103. ID Token

The ID token contains claims describing the authentication event and user identity for the client.

It is used by the client to understand:

who authenticated.

Part LXV — Access Token Versus ID Token

104. Comparison

Part LXVI — OAuth Versus OIDC

105. High-Yield Comparison

OAUTH 2.0

AUTHORIZATION



OIDC

AUTHENTICATION / IDENTITY

ON TOP OF OAUTH 2.0

This distinction is one of the most important IAM exam concepts.

Part LXVII — SAML Versus OIDC

106. Comparison

Both can support federated authentication.

Part LXVIII — JSON Web Token

107. JWT

JSON Web Tokens are commonly used as compact containers for claims in modern identity and authorization environments.

A JWT may be:

• signed;

• encrypted;

• both depending on surrounding standards and construction.

108. Critical Trap

JWT does not automatically mean encrypted.

A signed JWT can provide integrity/authenticity while its claims remain readable.

109. Never Trust Merely Because It Looks Like a JWT

Validate appropriate:

• signature;

• issuer;

• audience;

• expiration;

• intended token use.

Part LXIX — Token Audience

110. Audience

A token should be accepted only by its intended audience.

Example:

TOKEN FOR:

payroll.example



SHOULD NOT AUTOMATICALLY WORK AT:

admin.example

Part LXX — Issuer

111. Issuer

The issuer identifies the trusted authority that produced the token/assertion.

A relying party should not accept identity tokens from arbitrary untrusted issuers.

Part LXXI — Expiration

112. Token Lifetime

Shorter token lifetimes can reduce exposure if a token is stolen.

However, overly short lifetimes may create:

• usability;

• availability;

• reauthentication burdens.

Again:

balance security and mission.

Part LXXII — Token Replay

113. Replay Risk

A stolen bearer token may permit an attacker to act with the token's authority until it:

• expires;

• is revoked;

• becomes otherwise unusable.

Protect tokens like sensitive credentials.

Part LXXIII — Federation Trust

114. Trust Configuration

Federated systems need trusted configuration concerning:

• issuer identities;

• endpoints;

• keys/certificates;

• allowed audiences;

• claims.

115. Trust Failure

ROGUE IdP

   │

   ▼

FAKE ASSERTION

   │

   ▼

APPLICATION ACCEPTS

   │

   ▼

UNAUTHORIZED ACCESS

The application must validate:

not merely the format, but the trust relationship.

Part LXXIV — Federated SSO

116. Federation + SSO

Federation allows identities to cross security domains.

SSO allows one authentication event/session to facilitate access to multiple authorized applications.

These concepts frequently work together.

Part LXXV — SSO Risk

117. Authentication Concentration

CENTRAL IDENTITY PROVIDER

      │

 ┌────┼────┬────┐

 ▼    ▼    ▼    ▼

APP1 APP2 APP3 APP4

Compromise of the central session may create broad impact.

Part LXXVI — Strong IdP Security

118. Protect the Identity Provider

Use appropriate:

• MFA;

• phishing resistance;

• administrative separation;

• monitoring;

• session management;

• recovery controls.

Part LXXVII — On-Premises Federation

119. On-Premises

An organization may operate an internal identity provider that federates with other applications or organizations.

Part LXXVIII — Cloud Federation

120. Cloud

Cloud identity services can authenticate users and provide federated access to SaaS applications.

Part LXXIX — Hybrid Identity

121. Hybrid

A hybrid environment may connect:

ON-PREMISES DIRECTORY

        │

        ▼

IDENTITY SYNCHRONIZATION /

FEDERATION

        │

        ▼

CLOUD IDENTITY

        │

        ▼

SAAS / CLOUD APPS

The current CISSP outline explicitly identifies on-premises, cloud, and hybrid federation.

Part LXXX — Active Directory and Cloud Identity

122. Hybrid Example

An enterprise may retain AD-based identities for:

• domain-joined systems;

• Kerberos-dependent applications;

while also using cloud identity for:

• SaaS;

• OIDC;

• SAML;

• modern authentication.

Part LXXXI — Identity Broker

123. Identity Broker

An identity broker intermediates between different identity systems or protocols.

Conceptually:

IDENTITY SOURCE

      │

      ▼

IDENTITY BROKER

      │

   ┌──┼────┐

   ▼  ▼    ▼

SAML OIDC LEGACY APP

124. Benefit

The broker can reduce the number of direct trust integrations required.

125. Risk

The broker becomes:

a high-value trust concentration point.

Part LXXXII — SCIM

126. System for Cross-Domain Identity Management

SCIM standardizes identity provisioning and management across domains.

RFC 7644 defines SCIM as an HTTP-based protocol designed to simplify identity management in multi-domain environments such as enterprise-to-cloud and inter-cloud scenarios.

Part LXXXIII — SCIM Is Not Authentication

127. Critical Distinction

SCIM primarily addresses:

Provisioning

not:

Authentication.

128. SCIM Operations

SCIM can support operations such as:

• create user;

• retrieve user;

• modify user;

• disable/delete user;

• manage groups.

RFC 7644 defines HTTP-based create, retrieve, modify, and delete operations for identity resources.

Part LXXXIV — SCIM Example

129. Joiner

HR SYSTEM

    │

    ▼

IAM PLATFORM

    │

    │ SCIM

    ▼

CLOUD APPLICATION

    │

    ▼

ACCOUNT CREATED

130. Leaver

EMPLOYEE TERMINATED

       │

       ▼

IAM SYSTEM

       │

       │ SCIM

       ▼

SAAS ACCOUNT

       │

       ▼

DISABLED / REMOVED

Part LXXXV — SCIM Versus SAML/OIDC

131. Comparison

Part LXXXVI — Just-In-Time Provisioning

132. JIT Provisioning

An application may create a local user account when a trusted federated identity first signs in.

This can simplify onboarding.

133. Risk

JIT provisioning should not automatically grant:

excessive default access.

Authorization still requires policy.

Part LXXXVII — Deprovisioning Matters

134. Federation Does Not Automatically Solve Lifecycle

A user may lose employment status.

The organization must ensure downstream systems:

• remove or disable access;

• expire sessions;

• update entitlements.

Part LXXXVIII — Federation and Privacy

135. Minimize Claims

An application should not receive identity attributes it does not need.

Example:

Expense application might need:

• employee identifier;

• department.

It may not need:

• home address;

• birth date.

Part LXXXIX — Claims Minimization

136. Principle

IDENTITY PROVIDER

      │

      ▼

ONLY NECESSARY CLAIMS

      │

      ▼

RELYING PARTY

This aligns identity architecture with:

• least privilege;

• data minimization;

• privacy by design.

Part XC — Authentication Failure Modes

137. Weak Protocol

Example:

reusable plaintext credential transmission.

Risk:

• interception;

• replay.

138. Weak Identity Provider

Strong federation protocol + compromised IdP:

insecure federation.

139. Weak Relying Party Validation

Valid protocol + application fails to validate audience or issuer:

insecure application.

140. Weak Recovery

Strong authentication + weak help-desk reset process:

authentication bypass.

Part XCI — Authentication System Design

141. Select Based on Requirements

Do not start with:

Which protocol is most modern?

Start with:

• who authenticates;

• what resource;

• what assurance;

• what environment;

• what interoperability requirement.

Part XCII — Protocol Selection Examples

142. Enterprise Windows Domain

Likely concepts:

• AD;

• Kerberos;

• LDAP.

143. Wi-Fi Authentication

Likely concepts:

• 802.1X;

• RADIUS.

144. Router Administration

Likely concept:

• TACACS+.

145. SaaS Federation

Likely concepts:

• SAML;

• OIDC.

146. Delegated API Access

Likely concept:

• OAuth 2.0.

147. Cross-Domain Provisioning

Likely concept:

• SCIM.

Part XCIII — Protocol Comparison Master Table

148. High-Yield Matrix

Part XCIV — SierraTec Secure AUTHLINK Model

149. AUTHLINK

Use the AUTHLINK model when evaluating authentication and federation questions.

A — Authority

Who is trusted to authenticate the identity?

U — Understand the Protocol Purpose

Is the technology for:

• authentication;

• authorization;

• federation;

• directory access;

• provisioning?

T — Token, Ticket, or Credential

What security artifact represents trust?

H — Harden the Trust Relationship

Validate:

• issuers;

• keys;

• endpoints;

• configurations.

L — Limit Authorization

Authentication should not automatically create unrestricted access.

I — Inspect Sessions and Activity

Monitor:

• logins;

• tokens;

• privileged actions;

• anomalies.

N — Never Confuse Authentication with Authorization

Especially with OAuth.

K — Kill Stale Trust

Revoke:

• tickets;

• sessions;

• tokens;

• federation relationships;

• dormant accounts.

Part XCV — AUTHLINK Diagram

150.

A

AUTHORITY

    │

    ▼

U

UNDERSTAND PURPOSE

    │

    ▼

T

TOKEN / TICKET / CREDENTIAL

    │

    ▼

H

HARDEN TRUST

    │

    ▼

L

LIMIT AUTHORIZATION

    │

    ▼

I

INSPECT ACTIVITY

    │

    ▼

N

NEVER CONFUSE AUTHN/AUTHZ

    │

    ▼

K

KILL STALE TRUST

Part XCVI — Worked Kerberos Scenarios

151. Scenario 1 — Ticket Granting Ticket

A user successfully authenticates and receives a credential that can later be used to request service-specific tickets.

What has the user received?

A. TGT
B. Access token
C. SAML assertion
D. CRL

Correct Answer

A

152. Scenario 2 — Service Access

A user already has a TGT and now needs access to a file server.

Which Kerberos component is involved in issuing the appropriate service ticket?

A. Ticket Granting Server
B. Certificate Authority
C. RADIUS server
D. OAuth client

Correct Answer

A

153. Scenario 3 — KDC

Why is the Kerberos KDC a particularly sensitive system?

A. It forms a central authentication trust point.

B. It only stores public web pages.

C. It performs network switching.

D. It provides fire suppression.

Correct Answer

A

154. Scenario 4 — Clock Skew

Multiple users suddenly experience Kerberos failures after a time service malfunction.

What is the MOST likely explanation?

A. Kerberos relies on sufficiently synchronized time for ticket/authenticator validity.

B. LDAP has stopped routing packets.

C. OAuth scopes expired.

D. VLANs are misconfigured.

Correct Answer

A

Part XCVII — AAA Scenarios

155. Scenario 5 — Network Access

An organization needs centralized authentication for enterprise Wi-Fi clients using 802.1X.

Which technology is MOST strongly associated with this requirement?

A. RADIUS
B. SAML
C. SCIM
D. OAuth

Correct Answer

A

156. Scenario 6 — Network Device Administration

The security team wants centralized login, command authorization, and accounting for router administrators.

Which technology BEST fits?

A. TACACS+
B. OAuth only
C. SAML only
D. DNSSEC

Correct Answer

A

Part XCVIII — Federation Scenarios

157. Scenario 7 — SAML

An employee authenticates to a corporate IdP and then accesses a SaaS application using an XML-based signed assertion.

Which technology is MOST likely involved?

A. SAML
B. Kerberos only
C. RADIUS
D. SCIM only

Correct Answer

A

158. Scenario 8 — OAuth

A photo-editing application is authorized to access only selected images in a cloud account without receiving the user's cloud password.

Which framework BEST matches?

A. OAuth 2.0
B. LDAP
C. Kerberos
D. TACACS+

Correct Answer

A

159. Scenario 9 — OIDC

A web application needs to know the identity of a user who authenticated through an external provider.

Which technology BEST fits?

A. OpenID Connect
B. OAuth alone
C. SCIM
D. RADIUS

Correct Answer

A

160. Scenario 10 — SCIM

A company wants to automatically create and remove user accounts in a SaaS platform when HR status changes.

Which protocol BEST fits?

A. SCIM
B. SAML only
C. Kerberos
D. IPsec

Correct Answer

A

Part XCIX — More CISSP Scenarios

161. Scenario 11 — Access Token Misuse

A developer uses an OAuth access token as the sole proof of user authentication even though the token was issued for API authorization.

What is the PRIMARY problem?

A. Confusing authorization artifacts with authentication identity.

B. Using too much MFA.

C. Excessive LDAP encryption.

D. Kerberos clock skew.

Correct Answer

A

162. Scenario 12 — OIDC Token

A relying application needs authenticated-user identity claims.

Which artifact is MOST directly associated with OIDC?

A. ID token
B. TGT
C. CRL
D. RADIUS Access-Reject

Correct Answer

A

163. Scenario 13 — SAML Audience

A SAML assertion issued for Application A is accepted by unrelated Application B.

Which validation most clearly failed?

A. Audience validation
B. Firewall availability
C. DHCP configuration
D. Disk encryption

Correct Answer

A

164. Scenario 14 — JWT

An administrator assumes a JWT is confidential merely because it is digitally signed.

What is wrong with this assumption?

A. Signing provides integrity/authenticity but does not inherently encrypt the claims.

B. JWTs cannot be signed.

C. JWT always means SAML.

D. JWT is a network-routing protocol.

Correct Answer

A

165. Scenario 15 — Federation

A company accepts login assertions from an unknown external identity provider because the assertion structure is valid.

What is the GREATEST weakness?

A. No trusted federation relationship has been established.

B. XML is always insecure.

C. SSO requires no trust.

D. Authorization automatically replaces authentication.

Correct Answer

A

166. Scenario 16 — SCIM Offboarding

A terminated employee can no longer authenticate to the corporate IdP, but the employee's SaaS account remains active with local credentials.

What process needs improvement?

A. Downstream deprovisioning/lifecycle synchronization.

B. Kerberos ticket issuance.

C. Fiber routing.

D. Packet filtering.

Correct Answer

A

Part C — Common CISSP Exam Traps

167. Trap — LDAP Equals Active Directory

No.

LDAP is a directory-access protocol.

Active Directory is a directory-service platform.

168. Trap — LDAP Is Only Authentication

LDAP can support authentication interactions, but its broader purpose is:

directory access.

169. Trap — Kerberos Sends Your Password to Every Server

No.

Kerberos relies on trusted ticket exchanges.

170. Trap — TGT Gives Access to Every Service Automatically

No.

A TGT allows the client to request:

service-specific tickets.

Authorization still matters.

171. Trap — Kerberos Eliminates Credential Theft

No.

Attackers may steal:

• tickets;

• service credentials;

• privileged keys.

172. Trap — RADIUS and TACACS+ Are Identical

No.

For CISSP memory:

RADIUS → network access.

TACACS+ → device administration.

173. Trap — TACACS+ Legacy Obfuscation Is Modern Encryption

No.

RFC 9887 now defines TACACS+ over TLS 1.3 and explicitly replaces weak legacy protection for that secure profile.

174. Trap — Certificate Authentication Is Secure Even If the Private Key Is Stolen

No.

Authentication depends on proving control of the private key.

175. Trap — SAML Means Authorization Only

SAML can carry multiple types of security assertions and is widely used for federated authentication/SSO.

176. Trap — OAuth Authenticates Users

OAuth is fundamentally an:

authorization framework.

177. Trap — OIDC and OAuth Are the Same

OIDC adds an identity/authentication layer on top of OAuth 2.0.

178. Trap — ID Token and Access Token Are Interchangeable

No.

ID token:

identity/authentication information.

Access token:

resource authorization.

179. Trap — Signed JWT Means Secret JWT

No.

Digital signatures do not automatically provide confidentiality.

180. Trap — SSO Gives the Same Permissions Everywhere

No.

Authentication may be centralized.

Authorization remains resource specific.

181. Trap — Federation Eliminates Local Authorization

No.

A relying party still determines:

what the authenticated identity may do.

182. Trap — SCIM Is SSO

No.

SCIM primarily supports:

provisioning and identity lifecycle operations.

183. Trap — Federation Automatically Deprovisions Every Account

Not unless lifecycle integration has been correctly implemented.

184. Trap — WebAuthn Private Keys Are Sent to the Website

No.

The authenticator uses the private key to generate cryptographic proof; the relying party uses the registered public key to verify it.

Part CI — Knowledge Check

185. Question 1

What is LDAP primarily used for?

A. Directory access
B. Packet routing
C. Disk encryption
D. Fire suppression

Correct Answer

A

186. Question 2

What is the primary Kerberos authentication authority?

A. KDC
B. CA only
C. RADIUS client
D. OAuth Resource Server

Correct Answer

A

187. Question 3

What does a TGT primarily allow?

A. Requesting service tickets
B. Encrypting disks
C. Creating VLANs
D. Signing software

Correct Answer

A

188. Question 4

Which Kerberos component issues service tickets?

A. TGS
B. LDAP client
C. RADIUS NAS
D. SAML SP

Correct Answer

A

189. Question 5

Which technology is most strongly associated with Wi-Fi/VPN network access AAA?

A. RADIUS
B. SAML
C. SCIM
D. OIDC only

Correct Answer

A

190. Question 6

Which technology is strongly associated with centralized router/switch administration?

A. TACACS+
B. OAuth
C. SAML
D. SCIM

Correct Answer

A

191. Question 7

What does SAML primarily exchange?

A. Security assertions
B. Ethernet frames
C. Routing tables
D. Disk blocks

Correct Answer

A

192. Question 8

OAuth 2.0 is primarily a framework for:

A. Delegated authorization
B. Physical authentication
C. Routing
D. Encryption-key destruction

Correct Answer

A

193. Question 9

Which OAuth role hosts the protected resource?

A. Resource Server
B. Client
C. Resource Owner
D. IdP only

Correct Answer

A

194. Question 10

What is an OAuth access token used for?

A. Authorized resource access
B. Kerberos ticket issuance
C. Physical entry
D. DNS resolution

Correct Answer

A

195. Question 11

What does OIDC add to OAuth?

A. Identity/authentication layer
B. Network routing
C. Full-disk encryption
D. File-system ACLs

Correct Answer

A

196. Question 12

Which token is most directly associated with OIDC authentication?

A. ID token
B. TGT
C. CRL
D. RADIUS packet

Correct Answer

A

197. Question 13

What does SCIM primarily provide?

A. Identity provisioning and management
B. Kerberos authentication
C. Network encryption
D. Database replication

Correct Answer

A

198. Question 14

Which technology commonly uses public-key credentials scoped to web relying parties?

A. WebAuthn
B. Telnet
C. FTP
D. SNMPv1

Correct Answer

A

199. Question 15

What should a relying party validate in a federated token/assertion?

A. Issuer, audience, validity, and cryptographic trust as applicable
B. Screen resolution
C. CPU speed
D. Office location only

Correct Answer

A

200. Question 16

What is a primary risk of SSO?

A. Compromise of central authentication/session trust can affect multiple applications.

B. SSO eliminates user identity.

C. SSO prevents MFA.

D. SSO eliminates authorization.

Correct Answer

A

201. Question 17

What is hybrid identity?

A. Identity architecture spanning on-premises and cloud environments.

B. Two passwords.

C. A firewall pair.

D. A biometric reader.

Correct Answer

A

202. Question 18

What does a signed JWT primarily provide?

A. Integrity/authenticity of claims when correctly validated.

B. Guaranteed encryption.

C. Physical access.

D. Network segmentation.

Correct Answer

A

203. Question 19

What should happen to a federated user's downstream access when the business relationship ends?

A. Revoke/deprovision access according to lifecycle policy.

B. Leave accounts permanently enabled.

C. Increase privilege.

D. Disable auditing.

Correct Answer

A

204. Question 20

Which statement is MOST accurate?

A. Authentication protocols, federation, authorization, and provisioning solve different identity problems.

B. OAuth, SAML, SCIM, and LDAP are interchangeable.

C. SSO eliminates lifecycle management.

D. Federation removes the need for authorization.

Correct Answer

A

Part CII — Original CISSP-Style Practice Questions

205. Practice Question 1

An application must locate users and groups in a centralized enterprise directory.

Which technology is MOST appropriate?

A. LDAP
B. OAuth
C. IPsec
D. SCIM only

Correct Answer

A

206. Practice Question 2

A Windows domain user authenticates once and accesses multiple internal services using time-limited service tickets.

Which system is MOST directly involved?

A. Kerberos
B. OAuth
C. SAML
D. RADIUS

Correct Answer

A

207. Practice Question 3

A network engineering team requires centralized per-command authorization and audit logging for router administrators.

Which protocol is BEST suited?

A. TACACS+
B. LDAP alone
C. SAML
D. OAuth implicit flow

Correct Answer

A

208. Practice Question 4

An enterprise wireless network uses 802.1X and must forward authentication requests from access points to a centralized AAA server.

Which technology is MOST appropriate?

A. RADIUS
B. SCIM
C. OAuth
D. SAML

Correct Answer

A

209. Practice Question 5

A SaaS application redirects employees to the corporate IdP and accepts a signed XML assertion after successful authentication.

Which technology is MOST likely being used?

A. SAML
B. LDAP
C. TACACS+
D. Kerberos service ticket only

Correct Answer

A

210. Practice Question 6

A mobile application needs limited permission to read a user's cloud contacts without learning the user's cloud password.

Which technology is MOST appropriate?

A. OAuth 2.0
B. LDAP bind
C. Kerberos TGT
D. TACACS+

Correct Answer

A

211. Practice Question 7

A web application already uses OAuth 2.0 but now needs a standardized way to determine which user authenticated.

What should be added?

A. OpenID Connect
B. SCIM
C. RADIUS
D. IPsec

Correct Answer

A

212. Practice Question 8

A company wants terminated employees automatically removed from multiple SaaS applications.

Which capability BEST supports the requirement?

A. SCIM-based provisioning/deprovisioning.

B. SAML authentication alone.

C. OAuth access tokens alone.

D. Kerberos tickets alone.

Correct Answer

A

213. Practice Question 9

An application receives a correctly signed identity token from a trusted issuer, but the token's audience identifies a different application.

What should the application do?

A. Reject the token.

B. Accept it because the signature is valid.

C. Ignore the audience.

D. Convert it to a password.

Correct Answer

A

214. Practice Question 10

A user authenticates through SSO, but the finance application grants administrator privileges simply because the user came from the trusted IdP.

What is the PRIMARY weakness?

A. Authentication trust was incorrectly treated as unrestricted authorization.

B. Federation failed to authenticate.

C. LDAP cannot store groups.

D. Kerberos clock skew occurred.

Correct Answer

A

Part CIII — Protocol Memory Table

215. If You See This, Think This

Part CIV — Kerberos Memory Table

Part CV — Federation Memory Table

Part CVI — Token Memory Table

Part CVII — Key Terms

Directory Service

Structured repository of identity and resource information.

LDAP

Lightweight Directory Access Protocol.

Active Directory

Microsoft enterprise directory service.

Domain Controller

Server providing AD domain and identity services.

Kerberos

Ticket-based network authentication system.

Principal

Identity known to Kerberos.

Realm

Kerberos administrative domain.

KDC

Key Distribution Center.

Authentication Server

KDC component involved in initial authentication.

Ticket Granting Server

KDC component issuing service tickets.

TGT

Ticket Granting Ticket.

Service Ticket

Kerberos ticket for a particular service.

RADIUS

Centralized network-access AAA protocol.

TACACS+

AAA protocol strongly associated with network-device administration.

Certificate Authentication

Authentication based on proving control of a cryptographic private key associated with trusted identity information.

Smart Card

Hardware credential capable of holding protected cryptographic material.

WebAuthn

W3C web authentication framework using public-key credentials.

Passkey

Passwordless public-key credential implemented through modern authenticators.

Federation

Trusted identity relationship across separately administered domains.

IdP

Identity Provider.

SP

Service Provider.

RP

Relying Party.

Assertion

Statement issued by a trusted identity authority about a subject.

SAML

Security Assertion Markup Language.

OAuth 2.0

Delegated authorization framework.

Resource Owner

Entity capable of granting OAuth resource access.

Client

Application requesting delegated OAuth access.

Authorization Server

OAuth server issuing access tokens.

Resource Server

Service accepting valid OAuth access tokens.

Access Token

Credential representing authorization to protected resources.

Refresh Token

Credential used to obtain new access tokens.

Scope

Defined extent of OAuth access.

PKCE

Proof Key for Code Exchange.

OpenID Connect

Identity/authentication layer built on OAuth 2.0.

ID Token

OIDC token communicating authenticated-user identity claims.

JWT

Compact representation for claims that may be signed and/or encrypted depending on construction.

SCIM

System for Cross-domain Identity Management.

Identity Broker

Intermediary among identity systems or federation protocols.

Hybrid Identity

Identity architecture spanning on-premises and cloud environments.

CISSP Exam Focus

For authentication-system questions, use this sequence:

WHAT PROBLEM?

     │

     ▼

DIRECTORY?

AUTHENTICATION?

AUTHORIZATION?

FEDERATION?

PROVISIONING?

     │

     ▼

WHO IS THE TRUSTED AUTHORITY?

     │

     ▼

WHAT ARTIFACT IS USED?

PASSWORD?

TICKET?

TOKEN?

ASSERTION?

CERTIFICATE?

     │

     ▼

WHAT DOES IT AUTHORIZE?

     │

     ▼

HOW IS TRUST VALIDATED?

     │

     ▼

HOW DOES TRUST END?

Remember:

• LDAP is primarily a directory-access protocol.

• Active Directory is a directory service that can use LDAP and Kerberos.

• Kerberos uses tickets and a trusted KDC.

• TGTs are used to obtain service tickets.

• Kerberos depends on protected KDC infrastructure and appropriately synchronized time.

• RADIUS is strongly associated with network access.

• TACACS+ is strongly associated with network-device administration and fine-grained AAA.

• As of December 2025, TACACS+ over TLS 1.3 is standardized by RFC 9887.

• Certificate authentication relies on private-key control.

• WebAuthn uses relying-party-scoped public-key credentials.

• Federation transfers trusted identity information across domains.

• SAML is XML-based and widely associated with enterprise federation/SSO.

• OAuth 2.0 is primarily authorization—not authentication.

• OIDC adds authentication/identity on top of OAuth 2.0.

• Access tokens and ID tokens serve different purposes.

• Signed does not automatically mean encrypted.

• Relying parties must validate issuer, audience, validity, and cryptographic trust.

• SSO centralizes authentication but does not eliminate local authorization.

• Federation does not eliminate identity lifecycle requirements.

• SCIM addresses identity provisioning rather than user authentication.

• Hybrid identity spans on-premises and cloud identity environments.

• Always distinguish:

  • authentication;

  • authorization;

  • federation;

  • provisioning.

Lesson Summary

Lesson Eighteen expanded IAM from concepts into the actual systems and protocols used to establish and transfer identity trust.

You began with directory services:

DIRECTORY

   │

   ▼

LDAP

   │

   ▼

USERS / GROUPS / DEVICES

LDAP provides a standardized mechanism for interacting with directory services.

You then examined Active Directory and Kerberos:

USER

  │

  ▼

KDC / AS

  │

  ▼

TGT

  │

  ▼

TGS

  │

  ▼

SERVICE TICKET

  │

  ▼

APPLICATION

Kerberos provides trusted third-party ticket-based authentication across potentially untrusted networks.

You learned to associate:

RADIUS

   ↓

NETWORK ACCESS



TACACS+

   ↓

NETWORK DEVICE ADMINISTRATION

and examined the December 2025 IETF update that standardizes TACACS+ over TLS 1.3.

You then studied modern public-key authentication:

PRIVATE KEY

STAYS PROTECTED

      │

      ▼

CRYPTOGRAPHIC PROOF

      │

      ▼

PUBLIC KEY

      │

      ▼

AUTHENTICATION

WebAuthn formalizes this model for web relying parties through scoped public-key credentials.

The second half of the lesson focused on federation:

USER

  │

  ▼

IDENTITY PROVIDER

  │

  ▼

ASSERTION / TOKEN

  │

  ▼

RELYING PARTY

NIST's current SP 800-63C-4 defines federation as enabling a trusted identity authority to provide authentication and identity information to separately administered relying parties.

You learned the crucial protocol distinctions:

SAML

FEDERATED ASSERTIONS



OAUTH

DELEGATED AUTHORIZATION



OIDC

AUTHENTICATION / IDENTITY



SCIM

IDENTITY PROVISIONING

OAuth 2.0 enables limited delegated access to protected HTTP resources.

OpenID Connect adds an authentication/identity layer on top of OAuth 2.0.

SCIM provides standardized HTTP-based identity provisioning and management across domains.

The central Lesson Eighteen principle is:

Authentication systems are trustworthy only when the organization understands who controls identity, which protocol performs which function, what ticket/token/assertion represents trust, how the relying system validates that trust, what authorization follows from it, and how the trust relationship is revoked when it is no longer appropriate.

Exam Readiness Check

Before proceeding to Lesson Nineteen, make sure you can explain without reviewing:

• What centralized authentication means.

• What decentralized authentication means.

• What a directory service is.

• What LDAP does.

• Why LDAP is not synonymous with Active Directory.

• What a Distinguished Name represents.

• Why LDAP communication may need protection.

• What Active Directory provides conceptually.

• Why domain controllers are high-value assets.

• What Kerberos does.

• What a Kerberos principal is.

• What a Kerberos realm is.

• What the KDC does.

• What the Authentication Server does.

• What the Ticket Granting Server does.

• What a TGT is.

• What a service ticket is.

• The complete conceptual Kerberos ticket flow.

• Why Kerberos uses tickets rather than repeatedly transmitting passwords to services.

• Why KDC protection matters.

• Why time synchronization matters.

• What pass-the-ticket means.

• What Kerberos ticket forgery means conceptually.

• What NTLM represents at a high level.

• What RADIUS is commonly used for.

• What TACACS+ is commonly used for.

• The CISSP-level difference between RADIUS and TACACS+.

• Why TACACS+ command authorization is useful.

• What changed with TACACS+ over TLS 1.3.

• How certificate authentication works.

• Why private-key protection matters.

• How smart-card authentication can provide MFA.

• What WebAuthn does.

• How public-key WebAuthn authentication differs from passwords.

• What passkeys are conceptually.

• What federation means.

• What an IdP is.

• What an RP/SP is.

• What an assertion is.

• Why federation requires a trust relationship.

• What SAML is.

• Why SAML is associated with XML.

• How SP-initiated SAML SSO works.

• How IdP-initiated SAML works conceptually.

• What OAuth 2.0 is designed to do.

• Why OAuth is authorization rather than authentication.

• The four core OAuth roles.

• What an access token represents.

• What a refresh token does.

• What scopes do.

• How authorization-code flow works conceptually.

• What PKCE accomplishes.

• What OIDC adds to OAuth.

• The difference between an access token and an ID token.

• What a JWT is.

• Why a signed JWT is not automatically encrypted.

• Why issuer and audience validation matter.

• Why token expiration matters.

• Why token replay is dangerous.

• How SSO and federation differ.

• Why SSO increases the importance of IdP protection.

• What on-premises federation means.

• What cloud federation means.

• What hybrid identity means.

• What an identity broker does.

• What SCIM does.

• Why SCIM is provisioning, not authentication.

• How SCIM helps joiner/mover/leaver processes.

• Why federation still requires deprovisioning.

• Why claims should be minimized.

• Why authentication must never be confused with authorization.

Coming Next

Lesson Nineteen: Authorization Models and Access-Control Enforcement

Lesson Nineteen will focus on CISSP Domain 5.4 — Implement and manage authorization mechanisms.

The current outline explicitly includes:

• Role-Based Access Control;

• rule-based access control;

• Mandatory Access Control;

• Discretionary Access Control;

• Attribute-Based Access Control;

• risk-based access control;

• policy decision points;

• policy enforcement points.

The lesson will cover:

• access-control subjects and objects;

• permissions;

• rights;

• privileges;

• entitlements;

• ACLs;

• access-control matrices;

• capabilities;

• owner-controlled access;

• labels;

• classification;

• clearance;

• need to know;

• DAC;

• MAC;

• RBAC;

• role hierarchy;

• role explosion;

• rule-based access;

• ABAC;

• attributes;

• contextual authorization;

• risk-based authorization;

• policy-based access control;

• Policy Decision Points;

• Policy Enforcement Points;

• Policy Information Points;

• Policy Administration Points;

• Zero Trust authorization;

• explicit deny;

• implicit deny;

• least privilege;

• SoD conflicts;

• access decisions;

• original authorization diagrams;

• knowledge checks;

• CISSP-style scenarios.

The central Lesson Nineteen question will be:

Once an identity has been authenticated, how should the organization determine exactly what that subject may access, under which conditions, and who or what is responsible for enforcing the decision?

Publication and Independence Notice

This lesson is independently developed educational material for the SierraTec Secure CISSP Certification Preparation Course.

CISSP is administered by ISC2. SierraTec Secure's course is independent certification-preparation material and should not be represented as official ISC2 training unless separately authorized.

Current Domain 5 alignment was verified against the official CISSP Examination Outline. Objectives 5.2, 5.3, and 5.6 address identification/authentication strategy, federated identity across on-premises/cloud/hybrid services, and implementation of authentication systems.

Current digital-federation guidance was aligned with final NIST SP 800-63C-4, published July 2025.

Kerberos was aligned with RFC 4120, LDAP with RFC 4511, RADIUS with RFC 2865, TACACS+ with RFC 8907 and the current TLS 1.3 update RFC 9887, OAuth with RFC 6749 and its current Security Best Current Practice RFC 9700, OpenID Connect with the OpenID Foundation Core 1.0 specification, and SCIM with RFC 7644.

The SierraTec Secure AUTHLINK model, diagrams, examples, knowledge checks, comparisons, and practice questions are original instructional material and are not actual, recalled, leaked, or official CISSP examination questions.