business goal:
    one employee identity
    one login entry
    consistent MFA policy
    centralized joiner / mover / leaver process
    less manual account creation in every system

technical pieces:
    IdP stores and verifies user identity
    LDAP / AD can store users, groups, passwords, and directory attributes
    SAML or OIDC carries login result to applications
    OAuth2 grants API access
    JWT carries claims for modern apps
    SCIM provisions and disables accounts

SSO:
    解决统一登录

SCIM / provisioning:
    解决自动创建、同步、禁用账号

RBAC / app authorization:
    解决登录后在系统里能做什么

MFA / device policy:
    解决登录风险控制

employee
    -> login at IdP
        -> IdP proves who the employee is
            -> app receives signed login result
                -> app creates session
                    -> app checks local role / group / permission

Microsoft Entra ID / Okta / Google Workspace / ADFS
    -> SAML / OIDC
        -> SaaS apps
        -> internal apps
        -> AWS IAM Identity Center
        -> Amazon Cognito User Pool

LDAP / Active Directory
    -> Keycloak / AD FS / Entra ID / Okta
        -> SAML / OIDC
            -> SaaS apps
            -> internal apps
            -> APIs

LDAP / AD:
    bind / search / group lookup
    stores users, groups, passwords, directory attributes

SSO IdP layer:
    browser redirect flow
    SSO session
    MFA / authentication policy
    signed SAML assertion
    OIDC discovery / token endpoint / JWKS
    JWT / claim / attribute mapping

company IdP
    -> SAML or OIDC
        -> Cognito User Pool
            -> OIDC / OAuth2 JWT
                -> web app / mobile app / backend API

upstream:
    Cognito 可以接公司 IdP，比如 SAML IdP 或 OIDC IdP

downstream:
    Cognito 又可以作为 OIDC provider 给你的应用发 JWT

before:
    GitLab has one password
    Jira has one password
    Grafana has one password
    internal admin has one password
    AWS console has IAM users

after:
    employee logs in with company identity
    each system trusts the company IdP
    MFA policy is centralized
    leaving employee can be disabled centrally

SAML:
    common for enterprise SaaS and older internal systems

OIDC:
    common for modern web apps, mobile apps, APIs, and developer-built apps

proprietary agent / LDAP / Kerberos:
    possible in older enterprise environments
    LDAP itself is directory access, not a modern browser SSO protocol

examples:
    Microsoft Entra ID
    Okta
    Google Workspace
    OneLogin
    Ping Identity
    ADFS
    AWS IAM Identity Center internal identity store
    Amazon Cognito User Pool, for app users

examples:
    GitLab
    Jira
    Confluence
    Grafana
    AWS IAM Identity Center
    internal admin system
    payroll system

IdP:
    identity provider

SP:
    service provider

OP:
    OpenID Provider, 发 token 的身份系统

RP:
    Relying Party, 使用 token 的应用

IdP:
    登录中心

App / SP / RP:
    需要登录的业务系统

LDAP / AD DS:
    directory layer
    stores users, groups, passwords, organization attributes
    supports bind, search, group lookup
    often also works with Kerberos in Windows domain environments

SAML / OIDC IdP:
    web SSO protocol layer
    handles browser redirect login
    creates SSO session
    signs SAML assertion or JWT
    publishes metadata / discovery / JWKS
    validates client redirect URI or SAML ACS URL

app
    -> LDAP bind/search
        -> LDAP / AD DS

app
    -> redirects user to IdP
        -> IdP authenticates user through local DB / LDAP / AD / upstream IdP
            -> app receives signed SAML assertion or OIDC token

LDAP / AD DS:
    source of users, groups, passwords

Keycloak:
    connects to LDAP / AD through User Federation
    maps LDAP users / groups / attributes
    adds SSO session, MFA, flows, clients, protocol mappers
    issues OIDC tokens or SAML assertions to apps

AD DS:
    directory service
    LDAP / Kerberos / domain account

AD FS:
    federation service
    SAML / WS-Fed / OIDC layer in front of AD

Microsoft Entra ID:
    cloud IdP
    modern workforce SSO / app federation / conditional access

if app only supports LDAP:
    app can authenticate directly against LDAP / AD DS

if app needs SAML / OIDC:
    use Keycloak / AD FS / Okta / Entra ID / similar IdP

if company already has LDAP / AD:
    keep it as directory source
    put an IdP layer in front for modern SSO

main use:
    browser-based employee login
    enterprise SaaS SSO
    legacy internal apps
    AWS IAM Identity Center external IdP integration

1. user opens app
2. app redirects browser to IdP
3. user logs in at IdP and passes MFA
4. IdP posts signed SAML assertion back to app ACS URL
5. app verifies signature and creates local session

NameID:
    user identifier

email:
    user email

displayName:
    human-readable name

groups:
    group membership, if mapped

department / title:
    optional HR attributes

enterprise SaaS:
    Jira, Confluence, GitLab, Slack, Salesforce, old admin tools

employee workforce SSO:
    company employees logging into company systems

systems that only support SAML:
    many older products support SAML before they support OIDC

mobile native login:
    OIDC is usually better

API authorization:
    OAuth2 access token is usually better

fine-grained API scopes:
    SAML is not designed for that

main use:
    web app login
    SPA login
    mobile app login
    backend API receives bearer token
    Cognito / Auth0 / Okta / Entra ID app integration

1. app redirects browser to authorization endpoint
2. user logs in at IdP
3. IdP redirects back to app redirect_uri with authorization code
4. app exchanges code for tokens
5. app receives ID token, access token, and maybe refresh token
6. backend verifies access token before serving API requests

ID token:
    proves user identity
    consumed by client app
    contains identity claims such as sub, email, name

Access token:
    authorizes API access
    consumed by backend API
    contains scope, client_id, groups, token_use

Refresh token:
    used to obtain new ID/access tokens
    stored carefully

new internal apps:
    use OIDC if app supports it

custom web/mobile apps:
    use Authorization Code + PKCE

API-centric architecture:
    backend can verify JWT locally

machine-to-machine:
    use OAuth2 client credentials, not user login

SaaS only supports SAML:
    use SAML

old app only understands headers/session:
    use reverse proxy or ALB auth pattern

want automatic employee lifecycle:
    OIDC alone is not enough; add SCIM/provisioning

OAuth2:
    authorization framework
    answers: can this client access this resource?

OIDC:
    identity layer on top of OAuth2
    answers: who is this user?

login:
    use OIDC

API permission:
    use OAuth2 access token and scopes

machine-to-machine:
    use OAuth2 client credentials

third-party SaaS:
    use SAML unless the vendor's OIDC support is clearly better

new internal web/app/API:
    use OIDC

AWS console and AWS account access:
    use IAM Identity Center

custom app already using Cognito:
    federate Cognito to company IdP with SAML or OIDC

employee identity source:
    Microsoft Entra ID / Okta / Google Workspace / ADFS

AWS console access:
    IAM Identity Center

self-built apps:
    Cognito User Pool or direct OIDC/SAML integration to company IdP

browser/mobile app token issuer:
    Cognito User Pool is a good choice

direct client access to S3/AppSync/etc:
    Cognito Identity Pool only when truly needed

employees
    -> company IdP
        -> IAM Identity Center
            -> AWS accounts / permission sets

employees
    -> company IdP
        -> Cognito User Pool
            -> app receives JWT
                -> backend API verifies JWT

customers / external users
    -> Cognito User Pool
        -> app receives JWT
            -> backend API verifies JWT

SSO solves:
    user can log in with central identity
    password and MFA are centralized

SSO does not always solve:
    create app-local user
    assign app-local role
    disable app-local user after resignation
    remove stale groups

critical systems:
    use SCIM or explicit automated provisioning

low-risk internal tools:
    JIT provisioning can be acceptable

high-privilege access:
    do not give admin role by JIT default

leavers:
    central IdP disable must quickly remove access

choose:
    company IdP + SAML SSO + SCIM where supported

why:
    SaaS vendors commonly support SAML
    SCIM reduces manual account creation/removal

Okta / Entra ID / Google Workspace
    -> SAML
        -> Jira / GitLab / Grafana / Slack

Okta / Entra ID
    -> SCIM
        -> create users and sync groups

choose:
    OIDC Authorization Code + PKCE

why:
    modern app integration
    JWT is easy for backend verification
    works well with APIs

browser
    -> company IdP or Cognito
        -> OIDC code flow
            -> backend verifies JWT
                -> app checks local roles

choose:
    ALB auth / reverse proxy auth / SSO gateway

why:
    avoid rewriting app immediately
    protect route before traffic reaches app

limitation:
    app may only know request headers
    fine-grained authorization still needs app changes

choose:
    AWS IAM Identity Center

why:
    designed for workforce access to AWS accounts
    supports permission sets
    integrates with external identity source

creating IAM users for every employee:
    hard to rotate
    hard to disable consistently
    weak governance

choose:
    Cognito User Pool or another CIAM provider

why:
    app-user login is different from employee workforce login
    supports sign-up, password reset, MFA, social login, app clients

employees:
    workforce IdP

customers:
    customer identity store

choose:
    OAuth2 client credentials or cloud-native workload identity

why:
    no human user exists
    machine identity should not use a human password

internal worker -> token endpoint -> access token -> API
EKS workload -> IRSA / Pod Identity -> AWS API
EC2/ECS/Lambda -> IAM role -> AWS API

phase 1: inventory
    list all systems
    record whether each supports SAML, OIDC, SCIM, JIT
    record current admin owners
    record current local admin accounts

phase 2: choose identity source
    Entra ID / Okta / Google Workspace / ADFS / IAM Identity Center internal store
    define MFA policy
    define groups and naming convention

phase 3: connect high-value systems
    AWS IAM Identity Center
    Git / CI/CD
    monitoring
    ticketing
    production admin tools

phase 4: provisioning
    enable SCIM where possible
    define default JIT role carefully
    automate leaver removal

phase 5: app modernization
    new apps use OIDC
    old apps use SAML or auth proxy first
    migrate local passwords out gradually

identity source:
    one authoritative employee source is selected
    HR joiner/mover/leaver process is connected or documented
    break-glass account policy exists

authentication:
    MFA required for employees
    phishing-resistant MFA considered for privileged users
    local passwords disabled where SSO is enabled

protocol:
    SAML for SaaS / legacy enterprise apps
    OIDC for new custom web/mobile/API apps
    OAuth2 client credentials for machine-to-machine

provisioning:
    SCIM enabled for important systems
    JIT default role is least privilege
    leaver deprovisioning is tested

authorization:
    groups map to application roles intentionally
    admin roles require separate approval
    app still enforces resource-level permissions

operations:
    IdP admin changes are audited
    failed login spikes are monitored
    SAML certificate rotation is tracked
    token verification failures are logged

mistake:
    think SSO means no local account exists
result:
    many apps still need a local user record for roles, preferences, ownership, audit

mistake:
    enable SAML but leave local passwords active for everyone
result:
    users can bypass central MFA and leaver process

mistake:
    map every IdP group into every app
result:
    tokens/assertions become large and authorization is hard to reason about

mistake:
    use email as permanent user id
result:
    email rename or domain migration can break identity mapping

mistake:
    use Cognito Identity Pool for normal API login
result:
    browser gets AWS credentials unnecessarily

mistake:
    only implement SSO without SCIM or leaver automation
result:
    login is unified, but old app accounts and permissions still accumulate