Testing Your SSO Before Agents Depend on It

In an SP-initiated flow the application receives an unauthenticated request, builds a SAML AuthnRequest or OIDC authorization request, redirects to the IdP, and validates the response against the request it issued. In an IdP-initiated flow the identity provider builds the assertion first and posts it to the service provider with no prior request (Scalekit, miniOrange).

The difference is correlation. SP-initiated flows carry a request identifier and a RelayState value the IdP must echo back unmodified, which gives replay protection and tight session control (Scalekit). IdP-initiated assertions have no request to match, so they must be trusted on signature and audience alone (Logto).

Agents hit both paths. A launch from a central console is IdP-initiated. A launch from a workflow is SP-initiated. Teams that test only the browser path find the gap in production.

How to run it:

1. Sign in through the application's login endpoint, not the IdP portal, and confirm an AuthnRequest was generated and matched.
2. Alter the RelayState or request identifier in flight and confirm the application rejects the response.
3. Start from the IdP application tile and confirm the assertion lands at the right consumer service endpoint.
4. Post an assertion with the wrong audience or no signature and confirm rejection.

Decision rule: if an agent re-authenticates on its own, after a refresh failure at 3 a.m. for example, SP-initiated must work and must be validated. IdP-initiated support is a convenience for human-launched agents only.

Toolkits such as the SAML libraries behind passport-saml handle request generation and validation and log the exact correlation failure (Scalekit). A SAML tracer extension shows the raw assertion.

SAML assertions carry a Conditions element with NotBefore and NotOnOrAfter timestamps, and the service provider validates them against its own clock. A difference of seconds can reject a valid assertion with messages like "assertion expired" or "assertion not yet valid" (cloud-iam). Causes include NTP misconfiguration, virtual machine drift after suspend and resume, and servers syncing to different NTP pools (same guide).

Worked example. An IdP issues an assertion valid from 10:00:00 to 10:05:00. A service provider running six minutes fast reads 10:06:00 on arrival and rejects it as expired. One running two minutes slow reads 09:58:00 and rejects it as not yet valid. Add two minutes of allowed skew and the effective window becomes 09:58:00 to 10:07:00, and both failures disappear (cloud-iam).

The tradeoff: a longer assertion lifespan gives tolerance but widens the replay window, and lifespans of 30 to 60 seconds are far more vulnerable to skew than a typical 5 minute window (cloud-iam).

How to run it:

1. Record the measured offset between the two hosts.
2. Move the application host clock five minutes forward. Assertions inside the window should pass if tolerance is configured.
3. Move it five minutes back. Assertions arriving before NotBefore minus tolerance should be rejected.
4. Write down the exact offset where acceptance becomes rejection. That is your operational margin; under 60 seconds, one NTP hiccup breaks agent workflows.
5. Leave the IdP clock alone so you isolate which side is tolerant.

The worst failure is not rejection. It is a service provider that skips timestamp validation and accepts expired assertions, turning skew into a replay surface. The second worst is zero tolerance with no alerting, where failures surface as support tickets.

A mock layer that rewrites timestamps in a captured assertion is enough, plus NTP monitoring on both sides. Container clocks follow the host, so a drifting hypervisor drifts every container with it (cloud-iam).

Agents usually take authorization from group membership in the token. That is convenient and fragile. Directory attributes map into SAML attributes or OIDC claims, and the channel has practical limits: HTTP headers, URL length on redirect bindings, and the IdP's release rules.

When a user belongs to many groups, one of three things happens. The claim truncates at a fixed count, the claim moves to a separate endpoint the application must call, or the IdP refuses to release it. None produce a clean error at the agent. A truncated list leaves the agent under-permissioned, which looks like an agent bug. If the IdP fails open on over-limit claims, the agent gets broader scope than intended. Both directions log as a normal login.

How to run it. Create a test user and add groups incrementally, capturing the token each time.

for n in 50 100 150 200 300 400; do
  assign_user_to_groups "$TEST_USER" "$n"
  token=$(request_token "$TEST_USER")
  groups=$(decode_claim "$token" "groups" | count_items)
  echo "assigned=$n claimed=$groups"
done

The step where claimed stops matching assigned is your limit. Test at least one value well above it, such as 200 groups, where enterprise directory sprawl tends to land. Repeat with realistic long distinguished names, since those consume more space than short ones. Run the sweep against both a SAML attribute and an OIDC claim; they often differ. Then confirm what your application does on truncation: deny, call the directory, or grant partial access. That behavior, not the limit, is what agents live with.

Decision rule: if agents depend on group claims for authorization, do not put authorization in the claim. Use the claim to identify the agent or delegating user, then resolve permissions server-side against a directory lookup or policy service. That also gives you a revocation point that does not wait for expiry.

Non-human identity guidance agrees: record each agent's credential type, owner, purpose, connected systems, permission scope, and deprovisioning criteria, and reduce blast radius with least privilege and short-lived access (Sweet Security).

A JWT decoder and assertion viewer cover inspection. Most IdPs expose group claim configuration and an overage behavior setting under a name specific to that product. A policy engine that resolves per request rather than trusting the token is the durable fix.

This is the check teams skip and the one that matters for long-running agents. Deleting a user or removing a group changes future authentications. It does not change tokens already issued.

Microsoft documents the mechanics: access tokens issued by Entra ID last one hour by default, and the app silently reauthenticates with the refresh token when the access token expires. Browser sessions are worse, because an application issues its own session cookie, the IdP cannot directly revoke a session token issued by an application, and an app might never return to the IdP while its session is valid (Microsoft).

An hour of stale access is a known risk for a human. For an agent making hundreds of calls a minute it is a large automated blast radius. The Cloud Security Alliance cites research finding nearly 50 percent of organizations had experienced non-human identity compromises, with successful attacks in 66 percent of those cases (CSA).

How to run it:

1. Establish a live agent session and confirm it reaches a protected resource.
2. Remove the user from the authorizing group.
3. Poll the resource every five seconds and timestamp the first denial.
4. Record the gap between removal and denial. Minutes rather than seconds is a window an attacker can use.
5. Repeat with the account disabled rather than the group removed; the two paths differ.
6. Repeat with a client credential if the agent authenticates without a delegated user.

A systematic review of revocation recommends a security epoch: bind every session, refresh family, and grant to a monotonic value on the account, accept a credential only if its epoch matches the current one, and fail closed at sensitive endpoints when current state cannot be fetched (OneUptime). Applied to agents:

accept(credential) only if:
  credential.agent_id == requested_agent
  credential.security_epoch == agent.security_epoch
  credential is active and not expired
  policy_check(credential.agent_id, resource) == allow

Continuous access evaluation is the mainstream answer inside Microsoft's ecosystem, aimed at invalidating access tokens near real time (Microsoft). SCIM handles lifecycle, creating, updating, and deprovisioning identities across connected systems in one operation so dormant agents do not stay active indefinitely (LoginRadius). Pair either with an epoch check in your own layer, because the IdP cannot revoke a session your application issued.

Run the four checks in any order, but run them on every IdP change rather than once at integration.

Store captured assertions and tokens as fixtures so the harness runs without a live IdP, and wire it into the deployment pipeline, because IdP configuration drifts like code.

If agents cross more than one provider, or you are building the agent platform alongside the integration, a short architecture conversation saves debugging time. Quanta Consulting offers a free 30-minute discovery call to scope it (https://quantaintelligence.ai/calendar).

"We tested login and it worked." That exercised the human path. The agent path exercises refresh, correlation, claim size, and revocation timing, which fail differently.

"Token expiry is our revocation mechanism." It is a backstop. An hour of default access token life is long for an automated caller (Microsoft).

"Group claims are simpler than a policy service." Only until a user joins the wrong number of groups. Server-side authorization survives truncation, renaming, and reorganization.

"Passkeys solve this." They raise the cost of impersonating a human. They do not change what the IdP asserts about groups, token lifetime, or timestamp validation. NIST's authentication guidance, including its treatment of authenticator binding and revocation events, covers the lifecycle side (NIST SP 800-63B-4, NIST authenticator event management), not your claim mapping.