Guides
The Plain-Language Guide to Identity, SSO, and Federation
Why identity is now the front door
Company security used to center on the office network. If someone was inside the building or connected to the internal network, they were closer to the systems they needed.
That model no longer reflects how most companies work.
Email, files, collaboration tools, finance systems, HR platforms, and business applications now live in the cloud. Users access them from browsers, phones, laptops, home networks, customer sites, airports, and shared workspaces.
That makes the account the new front door.
If someone has a valid username and password, they can look like a legitimate employee. The question is no longer only whether the network is protected. It is whether the organization can control how people sign in, which applications they reach, and what rules apply before access is granted.
HENNGE Identity helps centralize that decision.
The two roles in every login
Every cloud login has two basic roles.
Role | What it does | Plain-language example |
Identity provider (IdP) | Holds user accounts and verifies who someone is | The passport office |
Service provider (SP) | The application someone is trying to open | The border agent checking the passport |
The identity provider verifies the user. The service provider trusts that verification.
For example, when a user opens email, an expense tool, or another cloud application, the app doesn't always need to check the password itself. Instead, it can rely on signed proof from the identity provider.
That's the foundation for single sign-on.
What single sign-on means
Single sign-on, or SSO, means users prove who they are once to the identity provider, then use that verified identity to access multiple applications.
Instead of every app asking for a separate password, the app receives a short-lived, signed message confirming the user’s identity.
The app receives proof.
It doesn't receive the user’s password.
Why SSO matters
Fewer passwords
Users rely on one strong credential instead of many reused passwords across different applications.
One switch to cut access
When an account is disabled, access can be removed across connected applications instead of being shut off one app at a time.
One place for the rules
Authentication requirements and access conditions can be managed centrally instead of being configured separately in every application.
For users, SSO makes access simpler.
For IT teams, it makes access easier to control.
How SSO works
A typical SSO login follows a simple flow:
The user opens an application.
The application asks the identity provider to verify the user.
The user proves their identity once.
The identity provider sends signed proof back to the application.
The application grants access.
The important point is that the application trusts the identity provider to make the authentication decision.
This is why choosing where authentication happens matters. If HENNGE Identity is the identity provider, HENNGE becomes the place where login rules, MFA requirements, device checks, network conditions, and access policies can be evaluated.
SAML and OIDC: the two common protocols
SSO depends on protocols that let the identity provider and service provider exchange trusted information.
The two common protocols are SAML and OIDC.
Protocol | What it is | Where it is commonly used |
SAML | The older enterprise standard. It uses browser redirects and a signed XML document called an assertion. | Enterprise applications, Microsoft 365, Google Workspace sign-on |
OIDC | A modern standard built on OAuth 2.0. It uses compact signed tokens. | Mobile apps, newer web apps, single-page applications |
Most users never need to know which protocol is being used.
The application decides what it supports, and HENNGE Identity supports both.
What federation changes
Microsoft 365 and Google Workspace can act as identity providers.
So can HENNGE Identity.
Federation changes which system verifies the login.
When a domain is federated to HENNGE Identity, Microsoft 365 or Google Workspace stops verifying logins itself and redirects the user to HENNGE Identity instead.
The user experience looks like this:
The user enters their work email at Microsoft 365 or Google Workspace.
The federated domain redirects the login to HENNGE Identity.
HENNGE Identity verifies the user.
HENNGE sends signed approval back.
The user lands in the application they were trying to open.
The directory doesn't move.
User accounts can still live in Microsoft Entra ID, Google Workspace, or Active Directory. A one-way sync copies the user list into HENNGE Identity, but passwords aren’t synchronized. HENNGE Identity becomes the authentication authority, while the directory remains the source of user accounts.
In plain language:
Federation changes who verifies the login. It doesn't change where the accounts live.
Why federation matters
Federation matters because it creates a single checkpoint for access.
When logins for a federated domain flow through HENNGE Identity, access policies can be evaluated in one place. Those policies can use conditions such as:
Network address
Device recognition
User group
Target application
One-time password requirements
Access location
Service-specific rules
This gives organizations more control over how access is granted.
For example:
An office login may not require an extra code.
A coffee-shop login may require a one-time password.
A confidential system may be limited to the office network.
An expense tool may be reachable from a phone.
A recognized device may be treated differently from an unknown one.
The goal isn't to make every login harder.
The goal is to apply the right rule to the right access request.
What to watch during rollout
Federation can provide wider coverage than expected because many third-party applications already trust Microsoft 365 or Google Workspace for sign-on. If the domain is federated, those login flows may reach HENNGE Identity too.
That's useful because HENNGE Identity can become the final checkpoint for more services.
It also means policies need to be tested carefully.
An overly strict policy can block an application the team didn’t think to test. A practical rollout should confirm which applications depend on Microsoft 365 or Google Workspace sign-on, which users are affected, and which policies should apply before enforcement is expanded.
Start with the most important access flows.
Test the policy behavior.
Then expand deliberately.
Key terms
Term | Plain-language definition |
Identity provider (IdP) | The system that holds user accounts and verifies who someone is. In this guide, HENNGE Identity. |
Service provider (SP) | The application someone is trying to reach. It trusts the identity provider to verify the user instead of checking the password itself. |
Single sign-on (SSO) | Proving identity once to the identity provider, then reaching multiple applications without signing in again each time. |
SAML | A widely used enterprise SSO protocol that passes a signed XML assertion through the browser. |
OIDC | A modern SSO protocol built on OAuth 2.0 that passes a compact signed token. |
Assertion / token | The short-lived signed message an identity provider sends to vouch for a user. |
Directory | The authoritative list of user accounts and attributes, such as Microsoft Entra ID, Google Workspace, or Active Directory. |
Federation | The arrangement where Microsoft 365 or Google Workspace redirects authentication to a third-party identity provider. |
Access policy | The login rules HENNGE Identity evaluates to decide access and whether extra verification is required. |
One-time password (OTP) | A short-lived code used as a second factor in addition to a password. |
The practical takeaway
SSO isn't only about convenience.
It reduces password sprawl, gives IT a central place to manage access, and makes it easier to remove access when a user leaves or changes roles.
Federation takes that one step further. It allows HENNGE Identity to become the authentication authority for Microsoft 365, Google Workspace, and connected applications while user accounts remain in the existing directory.
For organizations moving more work into the cloud, this creates a cleaner access model:
One place to verify users.
One place to apply rules.
One place to strengthen sign-in across cloud applications.
HENNGE Identity becomes the checkpoint where access decisions can be made before users reach the tools and data they need.