SAML single sign-on

SAML-based Single Sign-On (SSO) gives members access to GitBook through an identity provider (IDP) of your choice.

This feature is included in the Enterprise plan.

GitBook easily integrates with your existing identity provider (IdP) so you can provide your employees with single sign-on to GitBook using the same credentials and login experience as your other service providers (such as Slack and Dropbox).

Using SSO, your employees will be able to log into GitBook using the familiar identity provider interface, instead of the GitBook login page. The employee’s browser will then forward them to GitBook, authenticated and ready to go. The IdP grants access to GitBook when SSO is enabled and GitBook's own login mechanism is deactivated. In this way, authentication security is shifted to your IdP and coordinated with your other service providers.

SAML SSO on GitBook is supported for all Identity providers, and works well with:

  • Azure

  • Google for Work / G Suite

  • Okta

  • OneLogin

Prerequisites for SSO with GitBook

  • Your company’s identity provider (IdP) must support the SAML 2.0 standard.

  • You must have administrative permissions on the IdP.

Setup on GitBook

You must be an organization admin to enable SSO for your GitBook Organization.

After configuring SSO on your IdP, you will be able to upload or enter metadata manually. When setup is successful, administrators will see a confirmation dialog and the the URL of the SSO login for end users will be displayed. GitBook does not send announcement emails when set up is complete. It is the responsibility of the administrator to notify company employees (and convey the login URL to them) so they can access GitBook via SSO.

You'll need to find three pieces of information to give GitBook:

  • A sign-in page URL (also called a login URL)

  • Identity Provider Issuer

  • An X.509 certificate

You can enter anything as a Provider Label, it'll be displayed in the the login page for your company employees.

Setup on the IdP

Most SAML 2.0 compliant identity providers require the same information about the service provider for set up. (GitBook is the service provider.) These values are specific to your GitBook Organization and are available in the “Settings” tab of the GitBook team where you want to enable SSO.

GitBook requires that the NameID contain the user’s email address. Technically we are looking for: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

Example on Google G Suite

GitBook also requires some attributes mapping:

Application Attribute

Category (Google G Suite)

User Field (Google G Suite)


Basic Information

First Name


Basic Information

Last Name

Example on Google G Suite

Creating end-user account

To add end-users, create accounts for these users in the IdP. The first time each new user logs in to GitBook via the IdP, a GitBook account will be created for each of them via automatic IdP provisioning. The user will have access to organization resources as an organization Member.

Set-up requires lower case email addresses. Do not use mixed case email addresses.

Default Role

On the SSO settings, you can set a Default Role. This role will be applied to every new organization's members:

  • Reader: read only access to all spaces

  • Writer: read and write access to all spaces

  • Admin: read, write and admin access

You can find more details about the permissions here.

The organization role can be edited per user at any moment in the Team settings.

Removing end-user accounts

Removing an end-user from the IdP will prevent the user from being able to login to the corresponding GitBook account, but will not remove the account from GitBook. We advise removing the end-users account from the GitBook org associated with IdP as well.

Automated deprovisioning is not yet supported, but we'll soon release a SCIM API.

Security notice

For security reasons, users who signed-up to an organization before the SSO was set up have to continue to log in normally. SSO will only benefit users who log in to an organization after the setup is complete. Admins could also ask prior SSO users to delete their account (or change their email) and then they should be able to login with SSO.