Quip supports Security Assertion Markup Language (SAML) 2.0 for single sign-on (SSO), allowing your organization to authenticate Quip users through a centralized identity provider (IdP) such as Okta, Microsoft ADFS, Ping Federate, or Salesforce. This article provides an overview of how SAML SSO works in Quip, the required configuration values, and how to test the setup before enabling it for all users.
In a SAML SSO setup, your identity provider (IdP) — the system that manages user credentials — authenticates users and sends a signed SAML assertion to Quip confirming the user's identity. Quip acts as the service provider (SP) — the application the user wants to access. When SSO is configured, users no longer need a separate Quip password.
To configure your identity provider for Quip, you need the following Quip SP values. Download these from the Quip Admin Console under Settings > Accounts & Access > Download Quip's Metadata:
https://[yoursite].quip.comhttps://[yoursite].quip.com/saml/loginExample: A company's IT team downloads Quip's metadata XML and uploads it to Okta when creating the Quip SAML application, which populates the Entity ID and ACS URL automatically without manual entry.
Use the Enable for Test Users option to enable SSO only for specific email addresses before rolling it out to everyone. This allows you to verify the configuration works for both IdP-initiated and SP-initiated flows without risking a login disruption for your entire organization.
If uploading a metadata file does not work, click Configure Manually in the Quip Admin Console to enter the IdP's SSO URL, entity ID, and certificate directly. This is useful when your IdP does not produce a standard metadata XML file.
Quip supports only one active SAML configuration at a time. If your organization requires multiple identity providers, use a federation service to aggregate them into a single IdP endpoint before connecting to Quip.
000389476

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.