6.3 Federation, SSO, MFA, Passwordless, and Session Management

Trust Beyond One Application

Federation allows one identity provider to authenticate a subject and provide assertions or tokens to another system. A workforce user may sign in through a corporate identity provider and access a SaaS application. A customer may use a social or government identity to access a service. A partner may use its own identity system to reach a business portal. The security issue is not only protocol support. It is whether the relying party should trust the identity provider, which claims are accepted, and how trust is monitored.

Single sign-on centralizes authentication so users do not maintain separate passwords for every application. SSO can improve security by reducing password reuse, enabling consistent MFA, and giving security teams one place to disable access. It can also increase impact because a compromised identity provider session may unlock many services. SSO needs strong administration, resilient availability, secure recovery, careful application onboarding, and monitored token use.

Common federation patterns use standards such as SAML for browser-based enterprise assertions, OpenID Connect for identity information built on OAuth 2.0 flows, and OAuth 2.0 for delegated authorization. A CISSP does not need to memorize packet fields to make sound decisions. The key is understanding which party authenticates, which party consumes claims, which scopes or attributes are released, how keys are managed, and how replay or token theft is reduced.

MFA requires more than one type of evidence. A password plus a one-time code is stronger than a password alone, but it may still be vulnerable to phishing or real-time proxy attacks. Push approval can be effective but may suffer from approval fatigue if users are trained to tap accept. Phishing-resistant methods such as FIDO-based security keys or platform passkeys bind authentication to the legitimate site and device in stronger ways.

Passwordless authentication removes the traditional shared secret from the sign-in ceremony. It may use passkeys, smart cards, certificates, device-bound credentials, or cryptographic authenticators. Passwordless can reduce help desk resets and credential stuffing risk, but rollout must address enrollment, device loss, shared workstations, accessibility, recovery, and user populations that cannot use the same devices every day.

Session management controls what happens after authentication. A session token, cookie, refresh token, or access token may remain valid after the original login. If tokens live too long, attackers gain more time to use stolen sessions. If lifetimes are too short, users may create workarounds or suffer productivity loss. Good design ties session duration to sensitivity, device trust, location, user behavior, and transaction risk.

Federation failures often appear as business integration problems, but they are governance problems. A SaaS application may request excessive attributes. A partner may not terminate users promptly. A relying party may accept tokens signed with stale keys. An application may map every federated user to a high-privilege default role. The security team should require documented trust agreements, data minimization, test plans, and a way to terminate or suspend trust quickly.

Step-up authentication is a practical way to balance usability and risk. A user may open a low-risk dashboard with an existing session, but changing payroll data, exporting customer records, registering a new MFA device, or granting admin privilege should require fresh authentication. Step-up controls should consider transaction value and potential harm, not just login time. The most sensitive actions may also require approval or dual control.

Recovery is part of authentication strength. If the primary login is phishing resistant but the recovery process only asks for weak knowledge questions, attackers will target recovery. Account recovery should use verified channels, trusted devices, help desk identity proofing, fraud monitoring, and delayed high-risk changes. Recovery events should be logged and reviewed because they are often the point where control strength collapses.

Logout and revocation are also policy decisions. Users expect logout to end access, but distributed applications may keep refresh tokens or downstream sessions alive. The organization should define whether logout is local or global, how quickly token revocation takes effect, and which systems must honor emergency termination. High-risk environments may need continuous access evaluation so changes in user status or device risk affect active sessions.

Federation and Session Review Checklist

• Confirm each relying party has a business owner, data owner, and approved trust purpose.
• Release only the claims and attributes needed for the application function.
• Protect identity provider administration with separate accounts, phishing-resistant MFA, and strong monitoring.
• Use stronger MFA and shorter sessions for privileged, remote, regulated, and high-impact actions.
• Test account disablement, group removal, token revocation, and logout behavior end to end.
• Monitor unusual token use, impossible travel, repeated MFA prompts, and new device enrollment.

The CISSP view is that SSO and federation are not automatically safer. They become safer when trust is explicit, administrative surfaces are protected, claims are minimized, sessions are bounded, and lifecycle events propagate reliably. The business benefit is simplified access, but the security requirement is disciplined control of the trust chain.