SSO and Session Management for Healthcare Apps

Single sign-on is the easy half. A clinician authenticates once and reaches the EHR, the PACS viewer, the lab system and the scheduling tool without typing a password again. The hard half is the opposite question: when does that access stop? On a shared workstation in a corridor, the answer decides whether the next person to walk up is operating as the last person who logged in.

Two timeouts, two different jobs

Teams routinely configure one and assume it covers both cases.

Idle timeout ends a session after a period of no interaction. It protects the abandoned workstation. In clinical areas it needs to be short — minutes, not hours — which is exactly why it is unpopular and why it needs a fast way back in.

Absolute lifetime ends a session a fixed time after sign-in regardless of activity. It bounds the damage from a stolen token, which idle timeout alone does not: an attacker replaying a token keeps it alive indefinitely by using it.

Proximity and the clean handoff

The mechanism that actually resolves shared-workstation sessions is badge-driven:

The property that matters is not convenience, it is attribution. If two clinicians share one Windows session, the EHR audit trail can still be correct provided the application authenticates individually — but if it does not, you have lost the ability to answer who viewed a record. That is both a security failure and a HIPAA audit-control failure.

Single logout is usually broken

SSO federates login. Logout is much weaker in practice. A clinician clicking "sign out" of the EHR frequently leaves the identity provider session and every other federated application still live. The next person taps the browser and is inside the lab system.

What to verify in your own estate:

• Does signing out of one application terminate the IdP session?
• Do the other federated applications actually honour the logout propagation?
• Does closing the browser end the session, or just hide it?
• Does locking the workstation end application sessions, or only the desktop?
• How long does a refresh token remain valid after the user signs out?

Test this by hand. Sign into three applications, sign out of one, then return to the others. The result is often surprising.

Token lifetimes are the silent risk

SSO issues tokens, and a token is a bearer credential: whoever holds it is the user. Long-lived refresh tokens are convenient and are precisely what an attacker wants from a compromised endpoint.

• Keep access tokens short — an hour or less
• Bound refresh token lifetime, and make it single-use with rotation
• Revoke on password reset and on termination — and confirm revocation actually invalidates existing sessions rather than only blocking new logins
• Bind tokens to the device where the platform supports it, so a stolen token is not portable
• Re-authenticate for sensitive actions regardless of an existing session

What to check this month

GuardsArm reviews SSO and session configuration across clinical application estates, including the single-logout and revocation behaviour that vendors rarely document accurately. Book a scoping call.