As passkeys become more popular for logins to websites and apps, companies that already use authentication via Single Sign-On (SSO) are especially left wondering if and how they can benefit from passkeys as well. Especially, in the enterprise context, when using SAML as SSO, this is a common question. The following article describes how passkeys alongside SSO can provide a secure and easy login experience for all users.
With single sign-on (SSO), users may securely login to several different applications and websites with just one set of credentials.
Enterprise Passkey Whitepaper. Practical guidance, rollout patterns and KPIs for passkey programs.
To easily grasp SSO, consider the authentication process for your app as a service that most developers create themselves. You are in charge of creating usernames and passwords, inserting them into a database, and verifying login information each time.
SSO-enabled apps let users log in using a third-party service, rather than keeping track of usernames and passwords themselves. These apps integrate with an Identity Provider (IDP) like Azure AD, Okta or OneLogin who takes care of it for you. These providers are typically more feature-rich and secure than what the average company would be able to create on their own.
SSO is one of key components of identity and access management (IAM) and should not be confused with a password manager that just stores credentials and inputs them into corresponding services.
To make things work and let users data be passed between different services, SSO tokens are issued. They allow a user logged in to one service to access related services without the need for reauthentication.
There are three main types of SSO solutions on the market:
Open authorization (OAuth):
OAuth provides application the ability for secure designated access. You can tell your Identity Provider (e.g. Facebook) that it is OK for another website to access your profile information without having to give this website your password. If the website suffers a breach, the password remains safe as authorization tokens are used to prove identity. Today, OAuth 2.0 is the most common OAuth version.
OpenID Connect (OIDC):
OIDC is the preferred authentication protocol for consumer websites and apps. It is easy to implement and is based on RESTful API endpoints which allows convenient cross-device and cross-platform usage. Most social logins such as Apple, Facebook or Google are utilizing OIDC.
Security Access Markup Language (SAML):
SAML is a widespread authentication protocol in enterprise environments. It allows users to log in to a company server that grants them access to various company applications, e.g. CRM.
Try passkeys in a live demo.
Cybercriminals' primary targets are usernames and passwords. Therefore, there is an attack vector every time a user logs into a website or app. As most people use the same or similar passwords across various accounts, a hacker is likely to be able to access other websites if they gain access through one inadequately protected website. SSO decreases the attack surface because users only log in once and use a single set of credentials.
Moreover, SSO allows fast and efficient authentication and access to real-time data, as system administrators have an overview of used services and can manage authorization conveniently.
SSO, however, just delays the password problem. Since all applications and data are protected by only one set of credentials, hackers will be able to access all programs protected by it if they possess this set. The password becomes a single point of attack.
This makes the use of passwords and other insecure authentication factors particularly dangerous. Further, SSO is not necessarily bound to a person. This means, for example, that anyone can log in to all applications on a device during the corresponding period when someone leaves the device unlocked.
Moreover, theintegration of SSO solutions into an application can be quite cumbersome as different Identity Providers have different flows that need to beimplemented.
As passkeys is the new standard for authentication in websites and apps, many companies that currently offer SSO are facing the question if and how they can benefit from passkeys. Especially, in the enterprise context, when using SAML as SSO, this is a common question.
There are three main reasons why enterprises should offer passkeys alongside SSO:
Therefore, a solution for platforms that have local users in addition to SSO users is necessary to provide all users with a secure and easy login. For the former, login with passkeys is a perfect solution.
See how many people actually use passkeys.
The local user is the segment this article keeps circling back to: no identity provider standing behind them, and a 2FA option most of them never switch on. Corbado Connect is built for that segment specifically. It adds passkey login, passkey creation and passkey management to the login page you already run, so your SAML or OIDC setup is untouched and SSO users keep being forwarded to their provider exactly as before. Getting local users to the security posture of a big tech login stops being an in-house project.
See how Corbado Connect ships this βPasskeys as the primary login: a passkey carries both factors already, the device and the biometric or PIN that unlocks it, so a local user who adopts one is covered without opting into anything extra. Creation lives in a separate append component that runs after a successful login, so you can start offering passkeys without redesigning the login screen first.
Passkeys as the second factor where the password stays: for local users you cannot
move off passwords yet, there is a dedicated second-factor login component. It is
exported from connect-react and has no connect-web-js mount method, so unlike login,
append and the passkey list it is a React component today. The
password step stays exactly as it is and the passkey takes the place of the code, which
removes the friction that keeps
2FA adoption low in this
group. It hands control back to your own flow through a fallback callback whenever the
ceremony cannot run.
Users manage their own credentials: the passkey list component shows each credential with its provider name and icon, the browser and OS it was created with, when it was last used and whether it is synced, and lets the user remove one. Without an IdP behind the local segment, that work otherwise lands on your support desk.
None of this has to go live for everybody on day one. A ruleset decides which clients see the offer, by platform, platform version, browser or device model, and you can replay it over the last week of recorded traffic to see who it would have reached. The UX gains follow from there: better conversion rates, fewer password reset flows and lower cost for manual password resets, without building your own passwordless authentication stack in house.
Try out Corbado's passkey solution. The UI component can be integrated without any risks in minutes.
Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert β
Currently, it is not possible to directly combine SSO and passkeys into a single unified flow. However, platforms can run both in parallel: SSO users are forwarded to their respective identity provider, while local users authenticate with passkeys.
Most platforms have a mix of SSO users and local users without enterprise SSO. Passkeys address the local user segment by providing phishing-resistant, passwordless authentication that the FIDO Alliance is standardizing across both B2B and B2C.
Corbado covers local users in two ways. Users who adopt a passkey get both factors in one step, since the device and the biometric or PIN that unlocks it are the two factors. Users who keep their password can be sent through a passkey as the second factor instead of a code, using the dedicated second-factor login component, which ships for React today. Which clients get either offer is controlled by a rollout ruleset.
SSO integrates directly with an Identity Provider such as Azure AD, Okta or OneLogin to issue tokens that grant access across applications without reauthentication. A password manager simply stores credentials and inputs them into services, without managing session tokens or centralized access control.
Related Articles
Table of Contents