A Practitioner's Guide to Authentication and Identity for WorkSpaces
Designing authentication for WorkSpaces Personal and Applications — covering directory services, federation, pre-session and in-session methods, MFA, and the real-world SSO patterns that actually work today.
1. Introduction
Over the years, I've had a lot of deep conversations with customers about authentication, identity and access management for End User Computing environments — organizations of all sizes, across a wide range of industries, each with their own security posture, compliance requirements, and identity infrastructure. The same questions and considerations come up again and again.
No matter the use case, no matter the customer, no matter the technology stack — some form of user authentication is always required. Yes, even when dealing with anonymous access. The challenge is that there are a lot of options and nuance. In the context of WorkSpaces alone, you have different considerations depending on the combination of services, delivery models, directory services, client platforms, operating systems, and more.
Having a clear definition of business, security, and technical requirements — and coming up with the right strategy for identity management and user authentication upfront — is critical for the success of any deployment. Security often has the last word in the IT org, and I've seen projects have to start over, and in some cases fail completely, because it was discovered during testing that the solution couldn't support a required authentication flow.
A lot of what follows is the same ground I cover in those conversations, so I figured it was worth putting into article form and sharing with the community. This guide covers authentication across the WorkSpaces services family — WorkSpaces Personal and WorkSpaces Applications. We'll cover directory services, federation, pre-session and in-session authentication, MFA, SSO architectures, and the questions that drive the design.
Throughout this guide, you'll notice labels indicating when something applies to a specific WorkSpaces service:
- [Personal] — applies to WorkSpaces Personal
- [Applications] — applies to WorkSpaces Applications
- Items without a label apply to both services.
We'll be covering a lot of ground in order to build a solid knowledge base — if this is an area you're looking to learn more about, it will be worth your time. The earlier sections build the foundation; Sections 7 and 8 are where it all comes together into real design decisions and a side-by-side view of what's supported — the part you won't easily find pulled together anywhere else. And for those just looking for a quick cheat sheet to confirm a particular combination of service, directory type, authentication method, or SSO capability, feel free to skip ahead to the WorkSpaces Authentication Matrix in Section 8.
2. Authentication Concepts & Terminology
Before diving into service-specific options, let's level-set on a few key concepts that will come up throughout this guide. We'll be exploring all of these through the lens of WorkSpaces services.
At its core, authentication is the process of verifying that a user is who they claim to be. Authorization is what comes after — determining what that authenticated user is allowed to do or access. While this guide focuses primarily on authentication, it's important to understand that the two work together: authentication establishes identity, authorization enforces permissions.
Pre-session authentication is the full chain of identity validation that happens before your session is ready to use. This includes authenticating into the WorkSpaces service itself and logging into the operating system hosting the user session. Think of it as everything that stands between a user clicking "connect" and actually being inside their desktop or application streaming session.
In-session authentication is what happens after you're already connected. You're at your desktop — now you need to log into the applications, web portals, access a database, or reach an internal tool. This is the application-layer authentication that occurs within the context of an active session.
Directory service is the system that stores and manages machine and user accounts — most commonly Active Directory. We cover directory services in depth in Section 3.
Identity Provider (IdP) is the system that manages and authenticates user identities — the authoritative source where users prove who they are. Examples include Microsoft Entra ID, Okta, Ping Identity, and AD FS.
⚠️ Directory service ≠ IdP. A directory service and an IdP are not the same thing, even though a single product can play both roles — Active Directory, for example, is a directory service, and pairing it with AD FS adds an IdP. Throughout this guide, when we say "IdP" we mean the federation layer used in combination with the directory service.
Service Provider (SP) is the system or application that relies on the IdP to authenticate users. In this context, the WorkSpaces services act as the service provider — they trust the IdP's assertion that a user is who they claim to be, and grant access accordingly.
Federation is the ability for user identities in one organization or domain to authenticate to services in a different organization or domain, without having to create new credentials.
Single sign-on (SSO) is the experience of authenticating once and gaining access to multiple resources without being prompted for credentials again.
⚠️ Federation ≠ SSO. Federation and SSO are often used interchangeably, but they are not the same thing. Federation establishes trust between domains; SSO is about the user experience of not being prompted multiple times. We often use federation to achieve SSO, and that can create confusion. Many customers assume that implementing federation alone will automatically provide an SSO experience, and that is not always the case — getting your users in the door is not the same as eliminating every subsequent credential prompt.
Protocol standards are the specifications that define how identity information is exchanged between parties. In the WorkSpaces context, the key protocols include SAML 2.0 (for federation and pre-session authentication), OIDC/OAuth 2.0 (for token-based authentication flows), LDAP (for directory queries and credential validation), and FIDO2/WebAuthn (for passwordless and hardware-key-based authentication). Understanding which protocols are supported by each service is essential for designing the right authentication architecture.
Multi-factor authentication (MFA) adds additional verification factors beyond a password — something you have (hardware key, phone), something you are (biometrics), or something you know (PIN). We'll look at where and how MFA is enforced in a WorkSpaces environment later in the guide.
3. Directory Services & Identity Foundations
The directory service you use is one of the most foundational decisions in a WorkSpaces deployment. It has a direct correlation to the authentication options available to you and the requirements you'll need to meet.
When we talk about directory services in this context, we're not just thinking about user identity. With WorkSpaces — or any VDI solution for that matter — we are deploying machines after all. Machine identity — where the WorkSpaces instance lives in terms of domain membership and how it's managed — is equally important. We start here because understanding where the machine identity resides sets the stage for everything else. We'll explore how directory services relate to user authentication and identity providers in later sections.
Now let's talk about the other half of the equation: user identity. This is the source of truth for who the user is — where their account lives, where their credentials are validated, and what the system checks when they try to authenticate. In some deployments the directory service plays both roles: it holds the machine's domain membership and serves as the user identity store. Active Directory is the classic example — the same AD that domain-joins the machine can also authenticates the user.
But the two roles don't have to live in the same place, and increasingly they don't. A WorkSpaces instance might be domain-joined to Active Directory for machine identity, while user authentication is handled by a separate identity provider (Okta, Entra ID, Ping) that federates in.
There's an important nuance here, though: even when the IdP is the one authenticating the user, in an AD-joined environment there must still be a matching user account in Active Directory. The IdP validates the user, but Windows ultimately logs them into the domain — so the IdP identity and the AD identity are linked, not independent. Understanding this relationship — machine identity in AD, user authentication potentially at a separate IdP, but still mapped back to an AD account — is the key to making sense of the authentication options that follow.
Active Directory (AD) is still the standard in most enterprises, and therefore the most common directory service in WorkSpaces deployments. You'll see AD in environments where users need to connect to AD-integrated resources like applications, file and printer servers, and where AD group policy (GPO) is the primary mechanism for machine and user environment configurations. See how directory options work for each service in Manage directories for WorkSpaces Personal and Using Active Directory with WorkSpaces Applications .
Microsoft Entra ID [Personal] is Microsoft's Identity as a Service (IDaaS) solution for all their apps across cloud and on-premises. We're starting to see some customers shift to a more cloud-native and modern way of managing Windows desktop clients. In this context, more enterprise customers are looking to manage all Windows desktops the same — whether it's a physical laptop or VDI — and Microsoft Intune and Autopilot integration is part of that modernization story. This is where Entra-joined is starting to come up in WorkSpaces conversations. See Create a dedicated Microsoft Entra ID directory with WorkSpaces Personal .
No directory (non-domain-joined) [Applications] fits any use case where users don't need access to internal or corporate domain resources and the needs around machine identity and management are minimal. The focus is mainly on application delivery with federated access. Independent Software Vendors (ISVs) delivering applications to their end users are a common example.
It's important to note that directory service options are WorkSpaces service dependent — not every service supports every option.
4. Pre-Session Authentication Options
Pre-session authentication is where most of the design complexity lives. This is the chain of events that takes a user from "I want to connect" to actually being inside their desktop or application streaming session.
The options available to you depend heavily on the directory service in play (as covered in the previous section) and the specific WorkSpaces service you're deploying. Let's break down what's available. The main options are SAML 2.0 federation, AD username and password, certificate-based authentication (CBA), and smart card.
SAML 2.0 Federation
SAML 2.0 is the most popular pre-session authentication option across WorkSpaces services today, and for good reason. The IdP provides a logon point that users are already familiar with, and it enables a wide range of secure access capabilities that customers need.
Whether you simply need to add MFA or complex conditional access controls, you are free to layer in whatever features and capabilities are available with your IdP of choice. I often say to customers: do whatever you need at the IdP level — as long as we get a valid SAML authentication token back, we will connect the user to a session.
Microsoft Entra ID and Okta are the two most popular IdPs we see in WorkSpaces deployments, but we support many others that are SAML 2.0 capable. For setup details, see Set up SAML 2.0 for WorkSpaces Personal and Set up SAML 2.0 for WorkSpaces Applications .
A key requirement for WorkSpaces Personal: to use SAML 2.0 authentication, the IdP must support unsolicited IdP-initiated SSO with a deep link target resource or relay state endpoint URL. Not all IdPs support this — Google Workspace is a notable example of one that does not.
AD Username and Password [Personal]
This is the simplest form and default authentication option for WorkSpaces Personal — just an Active Directory username and password. No federation, no IdP portal, just a direct credential prompt in the WorkSpaces client.
Certificate-Based Authentication (CBA)
CBA is complementary to SAML and AD authentication — it's not something you use as a standalone option. Its primary purpose is to provide a true SSO experience between the SAML IdP and the Windows machine by eliminating the Windows OS authentication prompt.
Here's the scenario: a user authenticates via SAML at their IdP and gets redirected to their WorkSpaces session. The problem is that Windows doesn't understand SAML — it can't use that token to authenticate the user at the OS level. Without CBA, the user is presented with a Windows interactive login prompt asking for their AD password. With CBA, a short-lived certificate is used to authenticate the user to Windows automatically as part of the connection process — no second prompt.
While CBA is optional, it is considered by many as critical to deliver on user experience. Have you ever seen a user who enjoys having to enter their password multiple times? There are other use cases for CBA, like scenarios where AD identities are decoupled from IdPs and where users may not know their AD credentials, but we can get into that in another article.
If you want to dive deep into CBA, check out these references:
How to Configure Certificate-Based Authentication for Amazon WorkSpaces
How to Configure Certificate-Based Authentication for Amazon AppStream 2.0
Simplify Certificate-Based Authentication for AppStream 2.0 and WorkSpaces with AWS Private CA Connector for Active Directory
How to Configure Certificate-Based Authentication for Amazon AppStream 2.0
Simplify Certificate-Based Authentication for AppStream 2.0 and WorkSpaces with AWS Private CA Connector for Active Directory
Smart Card Authentication
Smart card is also a complementary option for AD-integrated WorkSpaces deployments. It allows users to authenticate to the OS using a physical smart card (PIV/CAC) rather than a password. The smart card is redirected from the user's local endpoint into the WorkSpaces session for the OS logon. This is common in government and regulated environments where smart card–based authentication is mandated. See Use smart cards for authentication in WorkSpaces Personal and Smart card authentication for WorkSpaces Applications .
5. In-Session Authentication
Once a user is inside their desktop or application streaming session, the authentication story doesn't end. Users still need to access web applications, SaaS platforms, internal portals, databases, file shares, and other resources — each of which may require its own authentication.
The goal at this layer is to minimize friction. If we've done our job well during pre-session authentication, we can leverage that established identity to make in-session access as seamless as possible. The most common options here are Kerberos, the Entra ID Primary Refresh Token, WebAuthn redirection, and smart card redirection.
Kerberos
In AD-integrated WorkSpaces deployments, Kerberos does a lot of the heavy lifting for in-session authentication. Once the user is logged into a domain-joined machine, Kerberos tickets are issued automatically and used to authenticate to AD-integrated resources — file servers, intranet sites, SQL databases, print servers — without any additional credential prompts. This is the same experience users get on a physical corporate desktop, and it carries over naturally into WorkSpaces.
Entra ID Primary Refresh Token (PRT) [Personal]
On Entra–joined WorkSpaces, the Primary Refresh Token plays a role similar to Kerberos in AD environments. When the user signs into Windows with their Entra ID credentials, Windows obtains a PRT and uses it to sign them into Entra ID–protected resources, such as Microsoft 365 and supported applications, without additional credential prompts. Just like Kerberos, this is standard Windows behavior that carries over naturally into WorkSpaces.
WebAuthn Redirection [Personal]
WebAuthn (FIDO2/passkeys) enables passwordless authentication to applications from within the session. Users can authenticate to supported applications using security keys or platform authenticators, redirected from their local endpoint into the WorkSpaces session. This is increasingly relevant as more SaaS providers and internal applications adopt passkey-based authentication. See Enhancing security with WebAuthn redirection in Amazon WorkSpaces .
If your IdP accepts passkeys or security keys as a passwordless factor, signing in to it in-session can be as simple as touching a key, entering a PIN, or a face scan. From there, other apps protected by that IdP follow through standard in-session SSO.
Smart Card Redirection
For environments that use physical smart cards (PIV/CAC), smart card redirection allows the card reader on the user's local endpoint to be available inside the WorkSpaces session. This enables in-session authentication to applications and resources that require smart card–based credentials — such as signing documents, accessing classified systems, or authenticating to government portals.
6. Multi-Factor Authentication (MFA)
MFA is a non-negotiable in most enterprise environments today. The question isn't whether to enforce it — it's where and how. In a WorkSpaces deployment, there are multiple points where MFA can be enforced, and the right approach depends on your authentication architecture. We'll look at IdP-level MFA, smart card/PIV, and RADIUS, plus a note on client certificates.
IdP-Level MFA
The beauty of this model is that you inherit all the MFA methods your IdP supports — push notifications, TOTP, biometrics, and phishing-resistant FIDO2 factors like hardware security keys (e.g., YubiKey). On top of that, you get the broader access controls that come with it: conditional access policies, device compliance checks, risk-based step-up authentication, and more.
Because MFA happens at the IdP level, it's consistent across all your applications — not just WorkSpaces. Users get one MFA experience regardless of what they're accessing, and security teams get centralized policy management.
[Personal] A hardware security key used at the IdP for pre-session MFA can also be used in-session through WebAuthn redirection to applications that support it.
Smart Card / PIV
In government and highly regulated environments, smart cards (PIV/CAC) serve as both an authentication factor and an identity credential. As discussed in the pre-session section, smart cards can be redirected into the session for OS logon. They also serve as an MFA factor — the physical card is "something you have" and the PIN is "something you know."
RADIUS MFA [Personal]
I'm including this only because it remains a supported option as of this writing, and you will see it in our documentation and configuration settings. But no one should be using it these days — there is plenty of information out there on all its shortcomings. This is something we rarely see outside of customers supporting legacy systems. See Multi-factor authentication (AD Connector) for WorkSpaces Personal .
Honorable Mention: Client Certificate Authentication
Client certificates are worth mentioning, but they aren't considered a true factor for user authentication. A client (or machine) certificate primarily serves as device-level access control or posture validation — it authenticates the device, not necessarily the human user sitting at the keyboard. That said, it's relevant in Zero Trust architectures where proving the connection is coming from a trusted, managed device is part of the access decision.
Worth noting: WorkSpaces Personal has a built-in mechanism to support client certificate authentication, for those customers that don't have a capable IdP in place. See Restrict access to trusted devices for WorkSpaces Personal .
7. The Questions That Drive the Design
We've defined the concepts — pre-session and in-session authentication, federation, SSO, MFA, and directory services. Now it's time to dive into the discovery process: identifying the actual requirements and arriving at the best solution.
What follows are the questions I work through with customers when designing authentication for WorkSpaces. The focus is on the decisions that have the most impact on your architecture: directory service, WorkSpaces service capabilities, identity providers, and SSO
Is Active Directory in the picture — and what role does it play?
This is always where I start. The answer is usually "yes," and for good reason: Active Directory remains the most widely deployed directory service in the world. Still, it's worth understanding the needs behind that choice. The answer drives both the WorkSpaces services that can be used and the entire authentication architecture. It also tells you a lot about how things are managed today, and in some cases even hints at the types of applications being used.
Machine identity: These are the most common reasons we see customers domain-join their WorkSpaces:
- Users need access to domain resources, like file shares, printers, and AD-integrated applications, as part of their daily workflow.
- Group Policy (GPO) is the standard mechanism for image lockdown and user environment configuration.
- Existing management and security tooling depends on domain membership.
User identity: In an AD-joined deployment, Active Directory is usually the source of user identity as well. A few details about how user accounts are set up give you a good foundation for the rest of the design and help you spot complexities up front:
- Are user accounts in the same domain as the computer accounts?
- How are the sAMAccountName and UPN attributes set, and are any alternate UPN suffixes in use?
- Do user email addresses match the AD domain?
These details matter even more once an IdP is in the mix. Every user still needs a matching AD account, and the identifier the IdP sends has to map to it. When usernames, UPNs, email addresses, and the AD domain don't line up, that mapping takes more planning, which is why it's worth finding out up front.
Domain topology: Domain topology is a design consideration in its own right, well beyond authentication. Given the obvious overlap, though, it's worth touching on during authentication design as well: whether there are multiple domains or forests to consider, and any trust relationships the design needs to account for.
Challenging assumptions: Not every deployment has a clear reason for domain join. Sometimes the current VDI solution is domain-joined and that's simply the way it's always been. If users don't need domain resources and GPO isn't a hard requirement, alternatives such as non-domain-joined [Applications] or Entra-joined [Personal] could be a better fit. If the customer is moving device management to Entra or moving away from AD, that's the next question.
Is Entra-joined a requirement?
Not every deployment starts with AD. More customers are moving Windows device management to the cloud and want to manage every Windows desktop the same way, whether it's a physical laptop or a WorkSpace. In WorkSpaces, that means Entra–joined WorkSpaces, managed with Microsoft Intune and Autopilot.
Keep in mind that Entra-joined is a WorkSpaces Personal option only today. That leaves out WorkSpaces Applications and the non-persistent use cases.
A big question here, from a viability standpoint, is whether IAM Identity Center (IDC) is already in use today, and how it's set up. Entra–joined WorkSpaces rely on IDC to bring user identities from Entra ID into AWS. That requirement surprises most customers, and depending on the existing IDC configuration, it can be a blocker. Things to understand include whether it's an organization or account instance, how the external identity source is configured, and which Region it lives in. I won't go into the details here, but these are must-reads:
Create a dedicated Microsoft Entra ID directory with WorkSpaces Personal
How to use multiple instances of AWS IAM Identity Center
How to use multiple instances of AWS IAM Identity Center
A few other questions to work through:
- Is Entra-joined already the standard for physical Windows devices, or would WorkSpaces be the first?
- Do users still need access to AD-integrated resources such as file shares or legacy applications? If so, that points to a hybrid approach. There are several hybrid architectures combining Entra ID and AD, but they're beyond the scope of this guide.
Which WorkSpaces service(s) are you deploying?
This might seem obvious, but it's not always a settled decision by the time authentication design comes up. In fact, it's not uncommon to see customers go back and change the WorkSpaces service that had been initially selected and qualified once they get into authentication design — to better align with security and user experience requirements.
Each service has a different authentication surface:
- WorkSpaces Personal always requires a directory for both machine and user identity.
- WorkSpaces Applications offers the most flexibility when it comes to machine identity and user authentication options.
We'll cover service-specific authentication capabilities in detail in the WorkSpaces Authentication Matrix that follows.
What does your IdP landscape look like?
This is where I get into the specifics of what's already in place. Most enterprise customers aren't starting from zero — they have an IdP, they have policies, they have existing federation integrations across their application portfolio. The goal is to extend that into WorkSpaces, not reinvent it.
Key things I want to understand:
- Which IdP are you using? — Okta, Entra ID, Ping, ADFS, something else? This determines what capabilities are available to you and what the integration looks like.
- What policies are already enforced? — Conditional access, device compliance, risk-based step-up? Whatever you're already doing for other applications, you can likely do for WorkSpaces.
- Is there a single IdP or multiple? — Some organizations have different IdPs for different user populations (employees vs. contractors, corporate vs. acquired companies). This adds complexity to the WorkSpaces authentication design.
Is your IdP also your access portal?
Beyond user identity and authentication, the IdP often plays a critical role in the broader access layer architecture. To understand why, let's briefly distinguish two authentication flows:
- IdP-initiated — the user starts at the IdP portal, clicks the WorkSpaces tile in their application catalog, and gets redirected into their session.
- SP-initiated — the user starts on the WorkSpaces client side, which redirects them to the IdP for authentication before bringing them back.
Both are valid, but in most enterprise scenarios IdP-initiated is the dominant pattern — and for good reason. IdPs with application stores (like Okta or Entra ID) allow you to aggregate resources for users, giving them a single portal where everything they need is published and accessible. The IdP becomes the storefront for access.
This is a must-have to support use cases where users need access to multiple WorkSpaces services or multiple resources within a particular service. Common examples include:
- Users who need access to both WorkSpaces Personal (their full desktop) and WorkSpaces Applications (specific published apps)
- Users who may need access to multiple WorkSpaces Personal directories or multiple Application stacks — different environments for different roles or projects
- DR and multi-region deployment scenarios where the IdP is the redirection point — routing users to the right environment based on availability or location
In these scenarios, the IdP isn't just authenticating the user — it's the central hub for organizing and delivering access to the right resources.
IdPs vary in how much they do beyond authentication. Some — like Auth0 — focus primarily on authentication and don't include an application store. If you're on one of these and you need to aggregate access across multiple WorkSpaces services or resources, one approach is to add a portal layer in front of the WorkSpaces services. I've worked with large deployments that built a custom portal between the IdP and WorkSpaces; it's worth planning for, since it adds effort during both deployment and ongoing management. It's simply something to weigh when choosing or confirming the IdP for your environment — an IdP with a built-in application store handles this natively.
Where do you need SSO — and where is it possible?
SSO in a WorkSpaces environment spans multiple layers of the user flow. Tying back to the concepts from Section 2, authentication happens at distinct points:
True end-to-end SSO means the user authenticates once at the IdP and that identity carries through the OS logon and into the application layer without additional prompts. But not every deployment needs — or can achieve — SSO at every layer. The design question is: which layers matter for your use case, and what's the mechanism to bridge them?
Pre-Session SSO: IdP → OS
Once an IdP is in the mix — which is the case for most enterprise deployments today — there are two pre-session SSO patterns that apply depending on the directory service:
In AD-joined environments, the user must authenticate to Windows with Active Directory regardless of what happens at the IdP level. The IdP handles user identity verification, MFA, and conditional access — but Windows requires its own authentication event against AD. This is a critical point that is often overlooked during initial design.
The only mechanism to provide SSO in this context — bridging the IdP authentication to the Windows logon without prompting the user a second time — is Certificate-Based Authentication (CBA).
In non-domain-joined environments [Applications], pre-session SSO is already built-in — OS-level authentication is managed internally by the WorkSpaces service. The user authenticates at the IdP and the session connects without additional prompts. A temporary shadow account ("PhotonUser") is used automatically behind the scenes.
In-Session SSO: OS → Application Layer
For in-session SSO on its own, there isn't really a WorkSpaces-specific consideration — it should work the same as on any machine. Kerberos SSO works naturally in AD-joined environments. A user who authenticates to an IdP in-session gets SSO to federated apps. This is standard behavior regardless of whether you're on a WorkSpaces desktop or a physical laptop.
End-to-end SSO: IdP → OS → Application Layer
The goal here is the one most people picture when they say "SSO": the user signs in once at the IdP, and that identity carries all the way through — into the OS and on to every app they open in-session — with no further prompts. It's worth being clear about how much of that is actually achievable today.
The one fully supported path: AD-joined + CBA. On AD-joined WorkSpaces (both Personal and Applications), the user signs in at the IdP, CBA logs them into Windows with no password, and Kerberos then signs them into AD-integrated resources — file shares, intranet sites, and internal applications. After the IdP, there's no prompt at any step. This is true end-to-end SSO, and it covers AD-integrated apps and resources.
Entra Seamless SSO extends the path to Microsoft 365 and other Entra resources. If the environment also has Microsoft Entra Seamless SSO configured, the same Kerberos mechanism extends end-to-end SSO to resources that require an Entra sign-in, such as Microsoft 365 — the user reaches them without an additional prompt. Seamless SSO relies on identities synced from AD to Entra ID and is opportunistic: if the Kerberos exchange can't complete, sign-in falls back to a normal password prompt. And because Entra still evaluates the sign-in, policies like MFA or conditional access can require an extra step even when Seamless SSO succeeds. See Microsoft Entra Seamless SSO: how it works .
Getting as close as possible for everything else. Apps that authenticate against the IdP directly, rather than AD or an Entra sign-in covered above, sit outside that path — the user still signs in to the IdP again in-session. The closest you can get today is WebAuthn redirection [Personal]: if the IdP accepts a passkey or security key as a passwordless factor, that in-session sign-in is just a touch, a PIN, or a face scan rather than a password. Once it's done, other apps behind the same IdP follow through standard in-session SSO. It's not a single sign-on, but it gets you half-way there.
How far you can take any of this comes down to three things: the WorkSpaces service, the IdP's capabilities, and the client device. The matrix below lays out what's available at pre-session and in-session for the different services and directory configurations.
8. WorkSpaces Authentication Matrix
What's supported at each layer across WorkSpaces services and directory configurations. A check (✓) marks a function WorkSpaces provides directly; — means not available; notes flag conditions or limitations.
9. Looking Ahead
Authentication and identity management for WorkSpaces is an evolving space. New capabilities are released regularly, and the right design today may have even better options tomorrow. I plan to treat this as a living guide and update it as those capabilities become available, so it stays a reliable reference over time.
If there's anything you'd like to see covered, scenarios you've tested, or ideas for product enhancements, I'd love to hear them — leave a comment or reach out to me directly.
Revision History
| Date | Update |
|---|---|
| 2026-10-20 | Extended the end-to-end SSO pattern: with Entra Seamless SSO |
| 2026-10-13 | Initial publication |
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article