Single sign-on (SSO) lets people use one trusted login to open several applications, instead of keeping a separate password for each system. After you prove who you are to a central identity service, that service can tell other apps you are allowed in. For Hong Kong teams that use email, collaboration tools, finance software and custom web apps, SSO reduces password fatigue and clarifies who can reach which system.
How SSO works in plain language
Most business SSO setups involve two roles:
- Identity provider (IdP): the system that checks your login — often Microsoft Entra ID, Google Workspace, Okta or a similar directory. It holds user accounts and decides whether a sign-in succeeds.
- Service provider (SP) or application: the email suite, CRM, booking admin, cloud console or custom app that relies on the IdP instead of storing its own password for each person.
A typical browser flow looks like this. You open an application. The app redirects you to the IdP. You sign in there (often with a password plus multi-factor authentication). The IdP returns a short-lived assertion or token naming who you are and, sometimes, your groups or roles. The application trusts that message and starts a session without another password. This often uses standards such as SAML or OpenID Connect over ordinary API and browser redirects. SSO is therefore a form of system integration focused on identity.
Why it matters for business systems
- Fewer passwords to remember and reset. Staff who juggle many tools are less likely to reuse weak passwords when one corporate login covers the main apps.
- Faster onboarding and offboarding. Create or disable the account in the identity provider so connected apps can follow that change.
- Clearer access reviews. IdP groups and roles can map to who may open finance, HR or admin tools.
- Fits identity-first security. SSO sits alongside MFA and zero trust ideas: verify the person, then grant only the apps they need.
Illustrative example: A Hong Kong trading firm uses Google Workspace for email, a cloud accounting tool, and an internal order portal. Without SSO, each person keeps three passwords. With SSO, staff sign in through the company IdP; the accounting tool and portal accept that login. When someone leaves, IT disables the IdP account and connected apps stop accepting new sessions, subject to each app's configuration.
SSO and MFA work better together
SSO alone does not make a weak password safe. If the only check at the IdP is a reused password, one stolen credential can open many apps. Pairing SSO with MFA at the IdP means the second factor protects the connected applications. Many organisations require MFA for the IdP login, then use SSO so people are not asked again in every app on the same device and session — exact behaviour depends on product settings.
What SSO does not do
- It does not replace permissions inside each app. SSO says who you are. Roles, menus and data rights still need configuring in the application or via group claims from the IdP.
- It does not cover every legacy system automatically. Older software without SAML, OpenID Connect or a compatible connector may still need its own login.
- It does not remove session and device hygiene. A shared unlocked laptop with an active SSO session can still expose connected apps until the session ends or is revoked.
- It does not replace vendor checks. You still need to know where identity data is stored, how tokens expire, and who can approve new app connections.
What to ask your team or vendor
- Which applications will join SSO first, and which stay on local passwords for now?
- Which identity provider do we already use, and does each app support SAML, OpenID Connect or a vendor connector?
- Is MFA required at the IdP for all staff, or only for admins?
- How are groups and roles mapped from the IdP into each application?
- What happens when someone leaves — how quickly are sessions revoked across connected apps?
- Who may register a new application with the IdP, and how is that change logged?
Rolling out SSO is often part of tightening identity once several tools are in daily use. For how technine.io approaches identity controls and secure connections, see our cybersecurity and compliance work and system integration and automation services.
Frequently asked questions
Is SSO the same as a password manager?
No. A password manager stores many passwords and fills them into separate login forms. SSO replaces those separate passwords with one login that applications trust through the identity provider.
Do customers need SSO on a public website?
Usually not for ordinary shoppers. SSO suits employees, partners or B2B portals where the same people use several tools. Consumer sites more often use a simple account plus MFA when risk is high.
Does SSO mean one password forever?
No. You still change the IdP password on a sensible schedule or after an incident, and MFA still applies. The point is one strong login path for many apps.
What if one connected app is compromised?
SSO shares identity, not every database. You still isolate application data and revoke the affected app's trust or sessions. Review IdP logs and disable risky connections; ask a security adviser for steps that fit your setup.