SSO

Single Sign-On (SSO) allows users to sign in once and access many applications without further password entry. The authentication process is managed centrally by an Identity Provider.

How it works

A user signs in to the Identity Provider (IdP), for example, Microsoft Entra ID. When they open an application, it asks the IdP if the user is authenticated. The IdP responds with a signed token using SAML or OpenID Connect. The application trusts this token and skips its own login process.

For a practical example: a company connects 40 applications to SSO. When an employee leaves, disabling the central account is sufficient. All access is blocked immediately. Previously, accounts had to be deleted in each application individually, and some were forgotten.

What to look out for

• SSO centralises risk. A compromised account can access many applications. MFA is therefore mandatory.
• Check which applications still allow local accounts alongside SSO. These backdoors should be closed.
• Define how long sessions remain valid. Very long sessions make it easier to misuse stolen tokens.
• Monitor newly connected applications in the IdP.

Security benefits

SSO reduces the number of passwords employees need to manage. This lowers the risk of reused passwords. Additionally, all authentications pass through one central point. This greatly simplifies monitoring in the SOC.

Typical mistakes

A common mistake is an SSO project that stops at simple applications. Older, specialised applications with sensitive data are often left out. A second error is a lack of logging on the application side. The SOC can see the login, but not what happens afterwards.

How we implement it

We monitor authentications via your IdP and detect session and token misuse. We are happy to discuss architecture questions as part of our Security Consulting.