Jay had been staring at the session table for forty minutes. Not a database table—nobody queried databases in the factory. He was staring at a visualization the agent had generated: a branching timeline of every active session the Okta twin was tracking, color-coded by authentication method. Blue for SAML. Green for OIDC. A thin yellow line for the lone session using password-only auth, which they kept around as a legacy edge case.
"There are eleven active sessions right now," Jay said. "Three of them have conflicting group memberships."
Navan looked up from his notebook. The physical one, the one he kept for sketching state diagrams by hand. "Conflicting how?"
"User gets provisioned into the Engineering group via Okta push. But the SAML assertion for their active session still carries the old claim—Contractors. The session was created before the group membership changed. Real Okta doesn't invalidate the session when group membership updates. The twin has to replicate that behavior."
Navan set his pen down. "So the session carries stale claims."
"Until token refresh. And the twin has to know exactly when that happens. Not approximately. Exactly." Jay pulled up the behavioral model. Lines of structured specification scrolled past. "The refresh interval is configurable per application in the real Okta. Our twin has to honor that per-app configuration. Application A refreshes every hour. Application B refreshes every fifteen minutes. Same user, same session, different claim states depending on which app you ask."
This was the part that made session management in the Okta twin genuinely hard. It wasn't the happy path—user logs in, gets a token, token works. That was trivial. It was the temporal dimension. Sessions existed over time, and time changed things.
Navan was drawing again. A timeline with branching arrows. "What about concurrent sessions? Same user, two browsers?"
"The twin handles it," Jay said. "Each session gets its own lifecycle. If you revoke one, the other stays active. If an admin does a global session clear, both die. If the user's account gets suspended, all sessions terminate but the tokens already issued remain valid until they expire. Real Okta does that. Our twin does that."
"That last part seems like a bug."
"It's not a bug. It's the specification. Tokens are bearer instruments. Once issued, they're valid until expiry. Suspension prevents new tokens from being issued. It doesn't retroactively invalidate existing ones." Jay paused. "Unless you configure token revocation, which is a separate feature, which our twin also models."
Navan added another branch to his diagram. The paper was getting crowded.
"The claim transformation pipeline is the real beast," Jay continued. "Okta lets you write custom expressions that modify claims at assertion time. Group names get mapped to roles. Roles get mapped to entitlements. The twin runs the full transformation chain. If the expression references a user attribute that doesn't exist yet, it returns null, and the downstream service has to handle null gracefully."
"And if it doesn't?"
"That's what scenarios are for. We test every combination. Null claims, stale claims, conflicting claims, claims from sessions that should have been revoked but weren't because the revocation webhook hasn't fired yet." Jay leaned back. "The Okta twin isn't modeling a login page. It's modeling time."
Navan looked at his diagram. The branches had become a thicket. He turned to a fresh page and started over.
The stale claims during active sessions thing is SO real. I've been bitten by this exact behavior in production Okta. Love seeing it modeled explicitly.