SSO: single sign-on for OSH platforms

Single sign-on provides access to authorised applications using a corporate identity. It does not replace permissions or protection of each account.

In brief

Single sign-on provides access to authorised applications using a corporate identity. It does not replace permissions or protection of each account.

Contents
  1. What SSO means
  2. Authentication and authorisation are different
  3. What to agree before integration
  4. Departures, sessions and continuity
  5. Example of verification
  6. Scope of this entry
  7. Related concepts
  8. References

A–Z dictionary →

What SSO means

Single sign-on allows a person to authenticate and use several applications without repeating a separate login for each one. In a federated arrangement, an identity provider tells the application it has authenticated the user. Protocols such as SAML and OpenID Connect enable this exchange. The aim is to simplify access while maintaining consistent identity management.

Authentication and authorisation are different

Knowing who is accessing the system does not decide which files they may view. A site technician, worker and healthcare professional may share an identity provider while having different permissions. The application must enforce its authorisation rules. This distinction is essential for health data protection in OSH, particularly where operational and clinical documents coexist.

What to agree before integration

The compatible protocol, necessary identity data and method of linking them to existing accounts should be identified. Email addresses can change and are not always a stable key. Who creates a person’s account, adds them to groups and removes access must also be defined. SSO does not itself mean that this provisioning is automated.

Departures, sessions and continuity

Removing someone from the directory should not be considered complete without checking open sessions, local accounts and alternative access routes. The organisation needs to understand how revocation propagates and what happens when the identity provider is unavailable. Emergency access, if available, requires its own controls and review; it should not become shared accounts that bypass normal policy.

Example of verification

In a hypothetical example, a company connects its prevention portal to the corporate directory. Testing includes logging in as a worker, a technician and someone whose account has been removed. Both ease of access and visible documents and effective permission withdrawal are checked. Reaching the home screen demonstrates only part of the integration.

Scope of this entry

SSO describes an access architecture. Its availability, protocols and conditions must be checked with each provider. It does not establish that all applications support the same functions or remove the need for multifactor authentication, device protection and incident monitoring.

References

  1. Microsoft Learn: what single sign-on is. Official source
  2. NIST SP 800-63C-4: federation requirements. Official source

Editorial information

Publication date: 1 November 2026.

Editorial responsibility: Sabentis Editorial Team.

Author: Pablo RodríguezLinkedIn

Executive Vice President of the ORP International Foundation and Chief Financial Officer of Sabentis.

Request a Demo

Discover all that Sabentis can do for your organization.

Try Sabentis

request a demo
stars 5
GetApp Software Advice Capterra