Back to Details

identity-providers

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Identity Providers — cross-vendor authentication mechanics

身份提供商——跨厂商身份验证机制

This skill encodes how modern authentication protocols actually work at the level needed to detect abuse. It is vendor-neutral — specific platform telemetry lives in 
entra-id
, 
okta-identity
, and 
active-directory
.
本 skill 记录了现代身份验证协议在检测滥用所需粒度上的实际运作方式。它不限定特定厂商——特定平台的 telemetry 位于 
entra-id
、
okta-identity
和 
active-directory
。

1. OAuth 2.0 / OIDC token flows

1. OAuth 2.0 / OIDC token 流程

Authorization code flow (most common for web apps)

Authorization code flow（Web 应用中最常见）

User → App → Redirect to IdP /authorize
  → User authenticates + consents
  → IdP redirects back with authorization code
  → App exchanges code for tokens (POST /token)
  → IdP returns: access_token + id_token + refresh_token
Detection-relevant: The code-to-token exchange happens server-side. A replayed authorization code (
AADSTS54005
in Entra ID) indicates code interception.
User → App → Redirect to IdP /authorize
  → User authenticates + consents
  → IdP redirects back with authorization code
  → App exchanges code for tokens (POST /token)
  → IdP returns: access_token + id_token + refresh_token
检测相关性：code-to-token 交换发生在服务端。重放 authorization code（Entra ID 中的 
AADSTS54005
）表示该 code 遭到拦截。

Client credentials flow (service-to-service)

Client credentials flow（服务到服务）

Service → POST /token with client_id + client_secret (or certificate)
  → IdP returns: access_token (no refresh token, no user context)
Detection-relevant: No user interaction. Compromised client secrets enable persistent access. Monitor for: new credential additions to app registrations, token requests from unexpected IPs, expired secret usage.
Service → POST /token with client_id + client_secret (or certificate)
  → IdP returns: access_token (no refresh token, no user context)
检测相关性：没有用户交互。泄露的 client secret 可用于维持持久访问。应监控：app registration 中新增凭据、来自异常 IP 的 token 请求，以及使用已过期 secret 的情况。

Device code flow

Device code flow

Device → POST /devicecode → receives user_code + device_code
  → User visits verification URL, enters user_code, authenticates
  → Device polls /token with device_code until user completes auth
  → IdP returns tokens
Detection-relevant: Device code phishing — attacker sends the user_code to the victim, who authenticates on the attacker's behalf. The attacker's device receives the tokens. Detection: 
device_code
grant type from unexpected device/IP, or user authenticating device codes they didn't initiate.
Device → POST /devicecode → receives user_code + device_code
  → User visits verification URL, enters user_code, authenticates
  → Device polls /token with device_code until user completes auth
  → IdP returns tokens
检测相关性：Device code 钓鱼攻击——攻击者将 user_code 发送给受害者，受害者随后代表攻击者完成身份验证。攻击者的设备会收到 tokens。检测：来自异常 device/IP 的 
device_code
grant type，或用户对自己未发起的 device code 完成身份验证。

Resource Owner Password Credentials (ROPC)

Resource Owner Password Credentials（ROPC）

App → POST /token with username + password directly
  → IdP returns tokens
Detection-relevant: ROPC bypasses MFA and conditional access in many configurations. Its use in modern environments is almost always suspicious. Detection: 
grant_type=password
in token requests.
App → POST /token with username + password directly
  → IdP returns tokens
检测相关性：在许多配置中，ROPC 会绕过 MFA 和 conditional access。在现代环境中使用它几乎总是可疑的。检测：token 请求中出现 
grant_type=password
。

2. SAML assertion structure

2. SAML assertion 结构

xml
<saml:Assertion>
  <saml:Issuer>https://adfs.contoso.com/</saml:Issuer>
  <ds:Signature>...</ds:Signature>
  <saml:Subject>
    <saml:NameID>user@contoso.com</saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore="..." NotOnOrAfter="...">
    <saml:AudienceRestriction>
      <saml:Audience>urn:federation:MicrosoftOnline</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AttributeStatement>
    <saml:Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
      <saml:AttributeValue>user-guid</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>
xml
<saml:Assertion>
  <saml:Issuer>https://adfs.contoso.com/</saml:Issuer>
  <ds:Signature>...</ds:Signature>
  <saml:Subject>
    <saml:NameID>user@contoso.com</saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore="..." NotOnOrAfter="...">
    <saml:AudienceRestriction>
      <saml:Audience>urn:federation:MicrosoftOnline</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AttributeStatement>
    <saml:Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
      <saml:AttributeValue>user-guid</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Golden SAML attack

Golden SAML 攻击

Preconditions: Attacker has the ADFS token-signing certificate private key.
Mechanism: Forge SAML assertions for any user, any role, any audience — the relying party (e.g. Entra ID) trusts the signature.
Detection signals:
  • SAML assertion without corresponding ADFS authentication event
  • Token-signing certificate exported (EID 1007 on ADFS server)
  • Assertion 
    NotBefore
    /
    NotOnOrAfter
    window anomalies
  • Assertion claims that don't match the user's actual attributes in AD
  • TokenIssuerType
    = 
    External
    in Entra ID 
    SigninLogs
    when it should be 
    AzureAD
前提条件：攻击者拥有 ADFS token-signing certificate 的 private key。
机制：为任意用户、任意角色和任意 audience 伪造 SAML assertions——依赖方（例如 Entra ID）会信任该签名。
检测信号：
  • 没有对应 ADFS authentication event 的 SAML assertion
  • Token-signing certificate 被导出（ADFS server 上的 EID 1007）
  • Assertion 的 
    NotBefore
    /
    NotOnOrAfter
    时间窗口异常
  • Assertion 中的 claims 与用户在 AD 中的实际 attributes 不匹配
  • 当结果应为 
    AzureAD
    时，Entra ID 
    SigninLogs
    中的 
    TokenIssuerType
    = 
    External

3. Primary Refresh Token (PRT)

3. Primary Refresh Token（PRT）

The PRT is a long-lived token issued to Windows devices joined to Entra ID. It enables SSO across all Entra ID-integrated applications.
ConceptDetailDetection relevance
IssuanceIssued during Windows logon to Entra ID-joined/hybrid-joined devicesPRT is bound to the device's TPM-protected key
UsageTransparently presented to Entra ID during browser SSO
x-ms-RefreshTokenCredential
header in authentication requests
TheftExtracting PRT from device memory (e.g. 
BrowserCore.exe
, 
CloudAP
plugin)		Stolen PRT used from a different device — detectable via device ID mismatch
Pass-the-PRTUsing stolen PRT to authenticate as the user from attacker's device
DeviceDetail.deviceId
in 
SigninLogs
doesn't match the user's registered device
Detection: Correlate 
DeviceDetail.deviceId
in sign-in events with the user's registered devices. PRT usage from an unregistered device is high-signal.
PRT 是一种长效 token，签发给已加入 Entra ID 的 Windows 设备。它支持在所有集成 Entra ID 的应用中使用 SSO。
概念详细信息检测相关性
签发（Issuance）在 Windows 登录已加入或混合加入 Entra ID 的设备时签发PRT 与设备由 TPM 保护的密钥绑定
使用（Usage）在浏览器 SSO 期间自动提供给 Entra IDAuthentication 请求中的 
x-ms-RefreshTokenCredential
header
窃取（Theft）从设备内存中提取 PRT（例如通过 
BrowserCore.exe
、
CloudAP
plugin）		从其他设备使用窃取的 PRT——可通过 device ID 不匹配进行检测
Pass-the-PRT在攻击者的设备上使用窃取的 PRT，以用户身份完成身份验证
SigninLogs
中的 
DeviceDetail.deviceId
与用户已注册的设备不匹配
检测：将登录事件中的 
DeviceDetail.deviceId
与用户已注册的设备进行关联。未经注册设备使用 PRT 是高信号。

4. Refresh token mechanics

4. Refresh token 机制

PropertyDetailDetection relevance
LifetimeTypically 90 days (Entra ID), configurable per IdPExpired token reuse = 
AADSTS70008
BindingCan be bound to device, IP, or sessionToken used from different device/IP = potential theft
RotationNew refresh token issued on each use (sliding window)Old refresh token reuse after rotation = replay attack
RevocationPassword change, admin revocation, session policyRevoked token use = 
AADSTS50173
FamilyRefresh tokens form a family; revoking one revokes allLimits blast radius of token theft
属性详细信息检测相关性
生命周期（Lifetime）通常为 90 天（Entra ID），可按 IdP 配置重用过期 token = 
AADSTS70008
绑定（Binding）可绑定到 device、IP 或 session从不同 device/IP 使用 token = 潜在失窃
轮换（Rotation）每次使用时签发新的 refresh token（滑动窗口）轮换后重用旧 refresh token = replay attack
撤销（Revocation）修改密码、管理员撤销、session policy使用已撤销 token = 
AADSTS50173
FamilyRefresh tokens 组成一个 family；撤销其中一个会撤销全部限制 token 失窃的影响范围

Token theft detection patterns

Token theft 检测模式

  1. IP change: Refresh token used from a different IP than the original authentication
  2. Device change: Token used from a different device fingerprint
  3. Concurrent use: Same refresh token used from two locations simultaneously
  4. Post-revocation use: Token used after password change or admin revocation
  1. IP 变化：Refresh token 的使用 IP 与最初身份验证时的 IP 不同
  2. Device 变化：Token 的使用设备指纹与原设备不同
  3. 并发使用：同一个 refresh token 同时从两个位置使用
  4. 撤销后使用：修改密码或管理员撤销后仍继续使用 token

5. Federation trust chains

5. Federation 信任链

ADFS → Entra ID

ADFS → Entra ID

User → ADFS (on-prem) → authenticates via AD
  → ADFS issues SAML assertion
  → Entra ID validates assertion signature against trusted certificate
  → Entra ID issues OAuth tokens
Detection: 
TokenIssuerType
in 
SigninLogs
. 
AzureAD
= cloud-native auth. 
External
= federated. Monitor for unexpected federation sources.
User → ADFS (on-prem) → authenticates via AD
  → ADFS issues SAML assertion
  → Entra ID validates assertion signature against trusted certificate
  → Entra ID issues OAuth tokens
检测：查看 
SigninLogs
中的 
TokenIssuerType
。
AzureAD
= 云原生身份验证。
External
= 联合身份验证。监控异常的 federation 来源。

Okta → Entra ID (inbound federation)

Okta → Entra ID（inbound federation）

User → Okta (source IdP) → authenticates
  → Okta issues SAML assertion
  → Entra ID (target) validates and issues tokens
Detection: 
system.idp.lifecycle.create
in Okta System Log. 
user.authentication.auth_via_IDP
for auth via external IdP. In Entra ID: 
TokenIssuerType
= 
External
.
User → Okta (source IdP) → authenticates
  → Okta issues SAML assertion
  → Entra ID (target) validates and issues tokens
检测：Okta System Log 中的 
system.idp.lifecycle.create
。通过外部 IdP 进行身份验证时对应 
user.authentication.auth_via_IDP
。在 Entra ID 中：
TokenIssuerType
= 
External
。

Trust chain abuse patterns

信任链滥用模式

AttackMechanismDetection
Golden SAMLForge assertions with stolen signing keyAssertion without IdP auth event
Federation hijackingAdd attacker-controlled IdP as trusted sourceIdP creation/modification events
Shadow federationCreate secondary federation relationshipNew federation trust in directory audit logs
Token signing cert rotationReplace legitimate cert with attacker-controlledCertificate change events on ADFS/IdP
攻击机制检测
Golden SAML使用窃取的 signing key 伪造 assertions没有对应 IdP auth event 的 assertion
Federation hijacking将攻击者控制的 IdP 添加为 trusted sourceIdP 创建或修改事件
Shadow federation创建次级 federation relationshipDirectory audit logs 中出现新的 federation trust
Token-signing certificate 轮换用攻击者控制的 certificate 替换合法 certificateADFS/IdP 上的 certificate change events

6. MFA ceremony flows

6. MFA ceremony 流程

Push notification (Okta Verify, Microsoft Authenticator)

Push notification（Okta Verify、Microsoft Authenticator）

User authenticates with password → IdP sends push to registered device
  → User approves/denies on device → IdP validates response
Vulnerability: MFA fatigue — repeated pushes until user approves. Detection: Multiple push denials followed by approval. Okta: 
outcome.result eq "FAILURE"
on 
user.authentication.auth_via_mfa
followed by 
SUCCESS
. Entra ID: 
ResultType 500121
(denied) followed by 
0
(success).
User authenticates with password → IdP sends push to registered device
  → User approves/denies on device → IdP validates response
漏洞：MFA fatigue——反复推送，直至用户批准。检测：多次 push 拒绝后紧接批准。Okta：在 
user.authentication.auth_via_mfa
中出现 
outcome.result eq "FAILURE"
，随后出现 
SUCCESS
。Entra ID：先出现 
ResultType 500121
（拒绝），随后出现 
0
（成功）。

FIDO2 / WebAuthn

FIDO2 / WebAuthn

User authenticates → IdP sends challenge → Authenticator signs challenge
  with device-bound private key → IdP validates signature
Phishing-resistant: The authenticator validates the origin (domain) — AiTM proxies cannot relay the challenge because the origin doesn't match. Detection: 
FastPass declined phishing attempt
in Okta. FIDO2 authentication events in Entra ID.
User authenticates → IdP sends challenge → Authenticator signs challenge
  with device-bound private key → IdP validates signature
抗钓鱼：Authenticator 会校验 origin（domain）——由于 origin 不匹配，AiTM proxy 无法中继 challenge。检测：Okta 中的 
FastPass declined phishing attempt
。Entra ID 中的 FIDO2 authentication events。

TOTP (Time-based One-Time Password)

TOTP（Time-based One-Time Password）

User authenticates → enters 6-digit code from authenticator app
  → IdP validates code against shared secret + current time
Vulnerability: Phishable — AiTM proxy can capture and replay the TOTP in real-time. Detection: TOTP authentication from known AiTM infrastructure (IP reputation), or TOTP followed by immediate session from different IP.
User authenticates → enters 6-digit code from authenticator app
  → IdP validates code against shared secret + current time
可被钓鱼——AiTM proxy 可以实时捕获并重放 TOTP。检测：来自已知 AiTM infrastructure 的 TOTP authentication（结合 IP reputation），或 TOTP 后立即从不同 IP 发起 session。

7. Policy-based access evaluation

7. 基于策略的访问评估

Modern IdPs enforce access decisions through policy engines that evaluate context at sign-in time. The concept is the same across vendors — only the implementation differs:
IdPPolicy engineEvaluation factors
Entra IDConditional AccessUser/group, app, device state, location, risk level, grant controls (MFA, compliance)
OktaAuthentication Policies + Global Session PolicyUser/group, app, device trust, network zone, behaviour
Google WorkspaceContext-Aware AccessUser/group, device, IP range, geo, device security posture
Detection-relevant: Policy bypass attempts and policy weakening are high-signal across all IdPs. Monitor for:
  • Access attempts blocked by policy (indicates probing or misconfiguration)
  • Policy modifications that remove MFA requirements or exclude privileged roles
  • Changes to trusted network/location definitions
For Entra ID-specific Conditional Access evaluation order, 
ResultType
codes, and 
AuditLogs
operations, see the 
entra-id
skill.
现代 IdP 通过 policy engine 在登录时执行访问决策。各厂商的概念相同——差异仅在实现：
IdPPolicy engine评估因素
Entra IDConditional Access用户/组、应用、设备状态、位置、风险等级、授权条件（MFA、合规性）
OktaAuthentication Policies + Global Session Policy用户/组、应用、设备信任、网络区域、行为
Google WorkspaceContext-Aware Access用户/组、设备、IP 范围、地理位置、设备安全状态
检测相关性：在所有 IdP 中，policy bypass attempts 和 policy weakening 都是高信号。应监控：
  • 被 policy 阻止的访问尝试（表明存在探测或配置错误）
  • 移除 MFA 要求或排除 privileged roles 的 policy 修改
  • 对 trusted network/location definitions 的更改
有关 Entra ID 特有的 Conditional Access evaluation order、
ResultType
codes 和 
AuditLogs
operations，请参阅 
entra-id
skill。

8. Quality checklist

8. 质量检查清单

  • Detection targets the protocol-level behaviour, not a specific IdP's UI.
  • OAuth grant type identified (auth code, client credentials, device code, ROPC).
  • Token lifetime and binding assumptions documented.
  • Federation trust chain understood (which IdP issues, which validates).
  • MFA ceremony type considered (phishing-resistant vs phishable).
  • Token theft detection covers IP change, device change, and concurrent use.
  • SAML assertion forgery conditions understood (signing key compromise).
  • PRT theft detection correlates device ID with registered devices.
  • Policy-based access bypass attempts monitored (Conditional Access, Okta policies, etc.).
  • Cross-IdP correlation uses email/UPN as the join key.
  • 检测目标是 protocol-level 行为，而不是特定 IdP 的 UI。
  • 已识别 OAuth grant type（auth code、client credentials、device code、ROPC）。
  • 已记录 token lifetime 和 binding 假设。
  • 已理解 federation trust chain（哪个 IdP 签发、哪个验证）。
  • 已考虑 MFA ceremony type（抗钓鱼还是可被钓鱼）。
  • Token theft detection 覆盖 IP 变化、设备变化和并发使用。
  • 已理解 SAML assertion 伪造条件（signing key 失陷）。
  • PRT theft detection 将 device ID 与已注册设备进行关联。
  • 已监控 policy-based access bypass attempts（Conditional Access、Okta policies 等）。
  • 跨 IdP correlation 使用 email/UPN 作为 join key。