Topic starter
14/07/2026 4:20 pm
TL;DR: PlainID says Duo SSO can now call its policy engine during token issuance so OIDC, OAuth and SAML claims reflect live authorization instead of stale configuration, and the same pattern can extend to MCP tool access decisions. Static tokens assume access stays valid after login; issuance-time authorization shifts trust to the moment the token is minted.
Editorial analysis by NHI Mgmt Group, based on content published by PlainID: “PlainID and Cisco Duo: Real-Time Authorization at SSO Sign-In”.
Key questions
Q: How should teams handle authorization when access decisions move into SSO sign-in?
A: Teams should treat sign-in as a policy checkpoint, not just an authentication event.
Q: Why do static SSO claims become risky when policy changes during a session?
A: Static claims are risky because they assume the user’s access state remains unchanged after login.
Q: What breaks when applications rely on token claims that were set at configuration time?
A: The break is freshness, not authentication.
Practitioner guidance
- Define which claims must be evaluated at issuance Separate stable identity attributes from claims that change with role, context, or data sensitivity.
- Treat the token pipeline as a governance boundary Document who owns the policy decision, who signs the token, and which audit record is authoritative when access is later reviewed.
- Map runtime decisions for agent and tool access Use the same policy source for human sign-in and delegated tool use when an agent or workflow acts on behalf of a user.
Bottom line: Real-time authorization at SSO sign-in makes the token reflect a live policy decision instead of a stale mapping from earlier configuration.
What's in the full announcement
PlainID's full article covers the operational detail this post intentionally leaves for the source:
- How Duo Inline Hooks evaluate PlainID policy during token issuance in OIDC and OAuth flows
- How SAML Assertion Inline Hooks modify assertions before signing for downstream applications
- How the External Authorization Hooks model applies to MCP tool access decisions
- How the runtime policy flow changes audit evidence for regulated enterprises
👉 Read PlainID's analysis of real-time authorization at SSO sign-in →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
14/07/2026 4:28 pm
Real-time token issuance is shifting authorization from application logic to identity infrastructure. That does not eliminate authorization complexity, but it changes where the decision is made and where the evidence lives. The practical consequence is that the token becomes a policy artifact, not just a session artifact, and identity teams have to govern that shift explicitly.
A few things that frame the scale:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
A question worth separating out:
Q: How do teams decide whether authorization should live in the IdP or the application?
A: Use the IdP for decisions that must be consistent at sign-in and shared across many applications, and keep application logic for app-specific checks that depend on local context. If the decision needs to be portable, auditable, and current at the moment of token issuance, the IdP is the better control point.
👉 Read our full editorial: Real-time authorization at SSO sign-in changes token trust
This post was modified 5 days ago by NHI Mgmt Group