A charging platform can pass every technical evaluation - hardware compatibility, OCPP version support, billing - and still stall in procurement because IT security won't sign off on how operator accounts get created and authenticated. For an enterprise or CPO buyer, that's almost always a single-sign-on question: does the platform integrate with the identity provider the rest of the business already runs on, or does it want its own separate username and password.
What SAML and OIDC actually do
SAML (Security Assertion Markup Language) and OIDC (OpenID Connect) are the two standards a charging platform uses to hand off authentication to an enterprise identity provider - Okta, Azure AD/Entra ID, Google Workspace, or an equivalent. Functionally they solve the same problem two different ways: instead of an operator console maintaining its own password database, a user logs in through the company's existing identity provider, and the platform trusts an assertion (SAML) or a token (OIDC) confirming who they are and, usually, what role or group they belong to. Neither standard is inherently “better” - SAML is older and more common in large enterprise IT estates, OIDC is newer and more common where the identity provider is cloud-native - and most enterprise identity providers support both.
Why enterprise IT asks for this before anything else
- Offboarding. When an employee leaves, disabling their account in the identity provider should immediately cut off access everywhere, including the charging console - not leave a separate, forgotten login active.
- Password policy and MFA. Security teams enforce password rotation, complexity and multi-factor authentication centrally. A platform with its own login is a gap in that policy, not an exception to it.
- Audit and compliance. Access reviews and compliance audits are built around the identity provider being the single source of truth for who can log into what. A vendor-specific login doesn't show up in that review.
- Fewer credentials to phish. Every additional standalone login is another password an employee can reuse or have phished. Federated identity collapses that down to one.
None of this is charging-specific - it's the same bar enterprise IT holds every SaaS vendor to. The difference is that charging platforms are newer entrants to a lot of these procurement processes, so it's worth confirming upfront rather than discovering the gap during security review.
Role mapping matters as much as login
SSO answers “who is this person,” not “what can they do once they're in.” A charging platform still needs its own role-based access control - site manager, regional operator, finance, read-only support - and the useful integration is mapping identity-provider groups to those roles, so adding someone to an Azure AD group is what grants them access to a site or a role in the console, rather than a second manual step inside the charging platform itself. Ask a vendor specifically whether role mapping is automatic from group membership or a separate manual assignment - the latter reintroduces the offboarding gap SSO was supposed to close.
What to ask a charging platform vendor
- Which protocols, and which providers are actually tested? “We support SAML” and “we've run SAML against Okta, Entra ID and Google Workspace in production” are different claims - ask for the second.
- Is role mapping automatic from identity-provider groups, or does every user still need a manual role assignment inside the platform after they first log in?
- Does SSO cover the operator console only, or the driver-facing app too? These are usually different identity flows - most enterprises only need SSO for internal operator/staff accounts, not for public EV drivers.
- What happens on identity-provider outage? Confirm whether there's a documented break-glass path so operations aren't locked out of the console if the identity provider itself has an incident.
- Is SSO gated to a specific pricing tier? Some vendors treat enterprise identity integration as an add-on rather than a baseline capability - worth knowing before it becomes a negotiation late in the deal.
CarChargeOS supports SAML and OIDC as part of its integration surface, with role-based access mapped to enterprise identity groups - see the full integration and security capability set on the platform page.
Frequently asked questions
Do I need SSO if my charging team is small?
It matters less at very small scale, but the requirement usually isn't driven by team size - it's driven by whichever part of the organization owns security policy. Many enterprises require SSO for any system with operator-level access, regardless of how many people actually use it.
Is SSO the same as multi-factor authentication (MFA)?
No. SSO federates login to your identity provider; MFA is a policy your identity provider enforces on that login. Once a charging platform supports SSO, MFA for it is typically inherited automatically from whatever the identity provider already requires.
Can drivers use the same SSO as operators?
Usually no, and usually shouldn't - operator SSO integrates with your corporate identity provider, while drivers authenticate through the branded consumer app with its own sign-up flow. Conflating the two is a common design mistake to watch for in a vendor's proposal.