Accounts & Identity Technical Explainer

What is single sign-on?¶

Single sign-on — SSO — lets one identity service authenticate a user for another connected service.

In practical terms, somebody may sign in to a work identity account and then open several connected applications without entering a separate password into each one.

For an investigator, that means the authentication evidence and the activity evidence may sit with different systems.

Two services may be involved¶

Identity providerChecks the userPassword, MFA, device or existing session.

Assertion / tokenConfirms accepted identitySigned information passed to the connected service.

Relying serviceCreates its own sessionThe user can now use the application.

The second service may never see the user's main password.

Where should you look for evidence?¶

At the identity provider, useful records may include:

primary authentication;
MFA events;
account recovery;
device or browser;
tenant or organisation;
application/client ID;
token issue; and
security alerts.

At the relying service, useful records may include:

the local session;
user/account mapping;
activity inside the service;
permissions;
resource access; and
logout or revocation.

You often need both sides.

SSO can explain a missing local password¶

Suppose a company cloud application shows activity by jpatel@northmere.example, but nobody can find a password for that application.

That may be completely normal if the user authenticated through the organisation's identity provider.

The important question is then:

Which identity-provider event created or authorised the service session?

Compromise can spread through connected services¶

If the identity-provider account is compromised, several connected applications may become accessible from the same trusted identity.

That can make the central identity account particularly important.

Equally, the relying service may keep its own long-lived session after the original sign-on.

So do not assume one authentication event explains every later action automatically.

Treat the records as connected but distinct¶

A successful identity-provider authentication can explain how access was granted.

The relying service records what happened after that.

The practical point is: with SSO, authentication and activity may live in different systems. Join the identity-provider event to the relying-service session rather than searching for a password that the second service never had.