Choose the Right Protocol and Flow

This is a scenario-based exercise. You will read eight real-world scenarios and select the correct authentication or authorization protocol and flow for each one. These are the kinds of decisions you will face as a GRC engineer when reviewing architecture diagrams, evaluating vendor SSO configurations, or advising engineering teams on which protocol to implement.

There is no partial credit here — each scenario has one best answer. Some scenarios include deliberate distractors, and one is a trick question designed to test whether you can distinguish authentication protocols from identity management protocols.

Before you start, here is the decision framework to apply for each scenario:

1. Is a user involved? If no, you are looking at machine-to-machine (Client Credentials or OIDC federation). If yes, continue.
2. What is the client type? Web app, mobile app, SPA, smart TV, CLI tool — this determines which flows are feasible.
3. Does the organization have existing infrastructure? AD FS, Okta, Auth0 — existing infrastructure constrains protocol choice.
4. What data needs to travel with the authentication? Just identity, or also roles, groups, and attributes?
5. Is this actually an authentication/authorization problem? Or is it provisioning, lifecycle management, or something else entirely?

Take your time. Read the scenario carefully, consider the constraints, and choose the most appropriate option.

Scenario 1: Enterprise SSO for legacy SaaS

A Fortune 500 company with 40,000 employees wants to connect Salesforce to their on-premises Active Directory for single sign-on. Their Active Directory Federation Services (AD FS) infrastructure is already deployed. Salesforce is a critical business application used by 8,000 sales representatives. The IT team wants a solution that works with their existing federation infrastructure without modification.

Scenario 2: Mobile banking authentication

A mobile banking application needs to let users log in and access their account data. The bank uses a modern identity platform (Auth0) as their authorization server. The mobile app is a native iOS and Android application. Users must authenticate before viewing balances, making transfers, or paying bills. The security team requires that tokens not be exposed in browser history or URL fragments.

Scenario 3: Microservice-to-microservice API calls

A microservice in a Kubernetes cluster needs to call another internal API to retrieve pricing data. No user is involved in the transaction — this is an automated backend process that runs every five minutes to update the product catalog with current pricing. Both services are deployed in the same cluster, but the security team requires authenticated API calls between all services regardless of network proximity. The organization follows a zero-trust architecture where network location alone does not establish trust.

Scenario 4: Smart TV streaming authorization

A smart TV application needs users to authorize their streaming account. The TV has no keyboard and no browser — only a remote control and a display. The user needs to link their existing account to the TV so the app can access their subscription data and playback history. The TV can display text and images on screen, and it can make HTTPS calls to external APIs, but it cannot render a web page or accept keyboard input beyond basic remote navigation.

Scenario 5: React SPA corporate authentication

A React single-page application needs to authenticate users against the company's Okta tenant. The application is a client-side SPA that runs entirely in the browser — there is no backend server. The security team has read the latest OWASP guidance and wants to follow current best practices for browser-based applications.

Scenario 6: Automated user provisioning

An HR system needs to automatically provision and deprovision user accounts across 15 SaaS applications whenever employees are hired or terminated. When a new employee is added to the HRIS, their account should be created in Slack, Google Workspace, GitHub, Jira, and 11 other applications with the correct role and group assignments. When an employee is terminated, their accounts should be deactivated in all 15 applications within one hour. The company already has SSO configured via Okta for all 15 applications, but account creation and removal is still done manually by IT administrators — a process that takes 2-3 days for onboarding and has resulted in two audit findings for delayed offboarding.

Scenario 7: Healthcare portal with role-based access

A healthcare portal must authenticate doctors and share their role (physician, nurse, administrator) and department (cardiology, emergency, radiology) with the electronic health record (EHR) system. The EHR system uses these attributes to determine which patient records each clinician can access — a cardiologist should see cardiology patients, but not radiology patients, unless they have been explicitly granted cross-department access. The hospital's identity infrastructure is built on an on-premises Active Directory with AD FS, and the EHR vendor (Epic) has provided integration documentation specifying which identity attributes must be transmitted during authentication.

Scenario 8: CI/CD pipeline deploying to cloud

A CI/CD pipeline running in GitHub Actions needs temporary cloud credentials to deploy infrastructure to AWS. The pipeline runs on every merge to the main branch, provisions Terraform resources, and then the credentials should expire. The security team does not want long-lived AWS access keys stored as GitHub secrets — the last security audit flagged static IAM access keys as a high-risk finding, and the remediation plan requires eliminating all static credentials from CI/CD pipelines within 90 days.

Scoring yourself

If you got all eight correct on the first attempt, you have a solid grasp of protocol selection. The scenarios you should pay the most attention to are the ones you hesitated on — those represent the edge cases you will encounter in real assessments.

The most commonly missed scenarios in this exercise:

• Scenario 5 — Many people still associate SPAs with the Implicit flow because older documentation and tutorials recommended it. Knowing that Authorization Code + PKCE has replaced Implicit for all client types is essential current knowledge.
• Scenario 6 — The SCIM trick question catches people who think SSO protocols handle the entire identity lifecycle. SSO handles authentication. SCIM handles provisioning. They are complementary but distinct.
• Scenario 8 — OIDC federation for CI/CD pipelines is relatively new (GitHub Actions added it in late 2021) and many organizations still use static access keys. Being able to recommend the modern approach is a differentiator.

What to carry forward

Protocol selection is not a theoretical exercise. Every application in your organization's portfolio is using one of these protocols (or should be). When you review an architecture diagram and see "SSO" drawn as a single arrow, you now know there are at least a dozen decisions embedded in that arrow: which protocol, which flow, which token lifetimes, which scopes, whether PKCE is enforced, whether assertions are signed and encrypted, and whether the configuration matches the use case.

The ability to match the right protocol to the right scenario — and to flag when the wrong one is in use — is what separates a GRC engineer who writes effective control narratives from one who copies vendor documentation without understanding it.

When you encounter a protocol decision in the wild, apply the five-question framework from the beginning of this exercise. Start with whether a user is involved. Consider the client type. Factor in existing infrastructure. Think about what data needs to travel with the authentication event. And always ask whether you are actually looking at an authentication problem or something else entirely.

This completes Module 2.3. You now have a working understanding of SAML 2.0 assertions, OIDC and OAuth 2.0 flows, the visual differences between protocols, and the practical judgment to select the right protocol for any given scenario. These skills will be applied directly in the remaining Phase 2 modules as you evaluate cloud IAM configurations, MFA implementations, and access governance programs.