Authentication Mechanism
Playground never sees or stores your password. People sign in at an identity provider, and Playground only receives a verified statement of who they are. Which mechanism is used depends on the login method.
| Login method | Mechanism |
|---|---|
| Google, Salesforce | OAuth 2.0 |
| SAML 2.0 (2.1.10 and later) | SAML 2.0 web single sign-on: sign-in can start from Playground or from your identity provider's app dashboard |
| OpenID Connect (2.1.10 and later) | OpenID Connect authorization-code flow with PKCE |
OAuth 2.0 (Google and Salesforce)
In the backend, we initiate a request to the selected identity provider at the time of login or signup and ask users to log in there. Once login is successful, the identity provider sends back some necessary information with which the user logs in to Playground, without disclosing any other resources.
It is safe as OAuth 2.0 is the industry standard to let users log in to applications via other applications.
SAML 2.0
- The identity provider sends a signed response. Playground verifies the signature with the identity provider's published certificate, and rejects responses that are unsigned or tampered with.
- The response must be addressed to your Playground (the audience and destination are checked) and must be within its validity window.
- Certificates can be rotated without downtime by adding the new one before the old one is retired.
OpenID Connect
- Playground uses the authorization-code flow with PKCE, together with state and nonce checks, so a sign-in cannot be replayed or injected from another browser.
- Tokens are validated against the signing keys your provider publishes.
Matching people to accounts
- Work emails: a private Playground accepts only emails on the domains its admins list, compared exactly (
company.comdoes not allowcompany.app). The same check applies to Google, Salesforce, SAML 2.0 and OpenID Connect. - Single sign-on identity: people are matched by email, or, when a unique identifier attribute (SAML) or claim (OpenID Connect) is configured, by the Unique ID stored on their account. Accounts are never linked or re-linked automatically, and there is no email fallback in Unique ID mode.
After you sign in
Once a sign-in is verified, Playground keeps you signed in with a signed session cookie. People are matched to their account by email address (see Login Methods).
Tools such as VS Code and MCP
The VS Code extension and MCP assistants do not use your login. They use app passwords that you generate yourself and can revoke at any time. Single sign-on policies that restrict people signing in do not break these tools.
note
Admins can require single sign-on for people signing in. Administrators can always use Google or Salesforce, so an identity provider outage can never lock every admin out. See Sign-in Methods & Policy.