Integrations

Single sign-on (SSO)

What’s single sign-on (SSO)?

Single sign-on (SSO) allows your users to enjoy a seamless experience when logging into the learning platform or visiting an O’Reilly content page. They’ll automatically log into their O’Reilly account using your company’s identity provider—no need for a username or password.

Benefits of using SSO include:

  • Improved online experience for your account members
  • Increased productivity
  • Reduced risk by minimizing bad password habits
  • Reduced help desk costs
  • Accelerated adoption of company-promoted apps

The O’Reilly SSO experience

When implementing SSO with O’Reilly, you’ll work with our integration team to create a simple and intuitive login experience for your users. You can customize login options based on your organization’s unique needs, so whether you have multiple accounts with us or use more than one identity provider (IdP), we’ll create a single unified login experience. Once your account has SSO configured and home realm discovery enabled, your users can also log in with SSO on the mobile app. If your IdP is behind a firewall, users will need to connect with mobile device pairing for mobile app logins.

To log in, users will simply enter their organization email address, select their group from the dropdown list (if applicable), and click Sign In with SSO. They won’t need to log back in to the platform unless they sign out or too much time has passed since their last login—a time frame you can choose (30 days by default).

Using SSO deep links

Our support of SAML SSO allows for deep linking, which authenticates a user and redirects that user to a specific area or title on the O’Reilly learning platform. These deep links can be used in communication with users in your organization, in a corporate portal, or to associate with learning events/objects in a learning management system.

User management with SSO

When integrated with SSO, you can use just-in-time user provisioning to manage your users’ accounts. This means the first time a user logs in, an account will automatically be created for them in O’Reilly. And you can set up no-touch reactivation so your deactivated users are automatically reactivated when they attempt to log in and open seats are available. These features help reduce the amount of time you’ll spend manually managing user accounts from your Admin Console.

You can also use settings within your identity provider to determine who can log in to O’Reilly. If that isn’t possible, we can evaluate the attributes sent for a user to determine whether or not they’re permitted to log in. Check with your local IT department to discover how authorization to applications is managed at your organization.

SAML 2.0

O’Reilly provides SSO through the well-established open source Security Assertion Markup Language (SAML), which is supported by most identity providers to authenticate users within corporations today. O’Reilly supports SAML 2.0, the most up-to-date version of the protocol. Our SAML service provider is Auth0. Below you’ll find the details you’ll need to configure your SAML identity provider for O’Reilly.

Supported SAML SSO flows

O’Reilly supports identity provider- and service provider-initiated SSO.

Service provider-initiated SSO flow:

  • A visitor requests an SSO-protected target resource from O’Reilly.
  • O’Reilly sends a SAML request to the partner identity provider.
  • The identity provider authenticates the visitor using its local authentication mechanism.
  • The identity provider sends O’Reilly a SAML response containing the visitor’s required information.
  • O’Reilly validates and confirms the SAML response, then grants access to the requested resource.

Identity provider–initiated SSO:

  • A visitor requests an SSO-protected resource via the identity provider.
  • The identity provider authenticates the visitor using its local authentication mechanism.
  • The identity provider sends O’Reilly a SAML response containing the visitor’s required information.
  • O’Reilly validates and confirms the SAML response, then grants access to the requested resource.

Recognized email domains (home realm discovery):

Users who visit the login page (https://learning.oreilly.com/accounts/login/) can trigger a service provider-initiated SAML login by entering an email address whose domain is registered to your corporate subscription.

SAML attributes

As a service provider (SP), we rely on assertions from our identity providers to perform account creation and user authorization. To provide the best user experience, we require the data below to be released as attributes in your SAML response.

O’Reilly attribute names Example source attributes Description of data
user_id urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

urn:oasis:names:tc:SAML:attribute:pairwise-id

user.ObjectID

eduPersonTargetedID		 Primary user identifier—must be unique, should never change.

Opaque privacy-preserving identifiers are strongly preferred, but we can use any attribute that is unique for each individual in your user base, even an email address, if necessary.
email urn:oid:0.9.2342.19200300.100.1.3

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress		 Deliverable email address
given_name urn:oid:2.5.4.42

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname		 First name(s)/given name(s)
family_name urn:oid:2.5.4.4

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname		 Last name(s)/surname(s)/family name(s)

Attributes for academic customers

The attribute requirements for academic customers are different from those for enterprise customers. Please refer to the Academic section of this page for details.

How to provide O’Reilly with your own attributes

O’Reilly can capture optional attributes, a feature you can use to pass along any attributes that you use on your own site for role-based authorization, reporting usage, and other tasks. For example, if your identity provider system sends a ”department” attribute in its SAML response, we’re able to capture and store that data for you. We can also map our attributes to attributes with other names that you may use for similar purposes.

If you need to prevent access to O’Reilly for a subset of users, we can evaluate their attributes to determine whether or not to allow them to log in to the platform. This should be discussed in detail to ensure we’re implementing your business rules as intended.

User anonymity

Upon request, we offer the ability to create anonymous user accounts. This can be done by using the customer-provided unique and unchanging identifier we require for each licensed user (see “SAML attributes” above). This allows the use of the O’Reilly learning platform without sharing any personal information.

User groups with SSO

You can use SSO to link groups in your identity provider with your groups in O’Reilly. For example, users could be grouped by department, location, or cost center.

To get started, please confirm that your IdP can release group information as an attribute in the SAML response and ask your IdP admin to release it to O’Reilly. Then let your O’Reilly customer success manager know you’d like to use SSO for groups. Our integration team will set up the connection and confirm when it’s ready to go.

In your Admin Console, you can create groups from the . Click the “Create a group” button, then provide a group name, group type, learning objectives, and the group’s external identifier. If you don’t have the external identifier yet, you can create your group without it and add it later.

The external identifier is your IdP’s unique label for a particular group. For example, if you’re grouping users by department, the external identifier might be “engineering,” “marketing,” or “sales.” And the group type would be “department.” If you don’t know the external identifiers for your groups, check in with your local IT department or the team in your organization that manages your IdP.

If you’re currently using flex fields to group your users, we can adjust our attribute mappings to allow your flex fields to be used with groups too.

See the Admin Guide for more details on creating groups.

Identity provider configuration

Once the service provider has been configured by O’Reilly, we’ll provide you with the following information via email:

  • A unique connection string
  • The entity ID of the service provider
  • The SP metadata download link
  • The assertion consumer service URL (a.k.a. postback URL or SSO URL)
  • The SP signing certificate
  • A dedicated sign-in URL for your users
  • Instructions for completing setup and testing

We have detailed steps on the setup needed within commonly used identity providers:

Our SAML requests are signed using a SHA256 hash algorithm. If needed, we can downgrade to signing requests using SHA1 or to unsigned requests. However, doing so is strongly discouraged. We require signed SAML responses and support attribute-level encryption.

Academic customers

For our academic library customers, our configuration is anonymous—based on a unique, persistent user identifier, such as the attribute eduPersonTargetedID or the SAML subject types pairwise-id or persistent-id. We don’t accept user identifiers that are PII-based and contain any portion of a library user’s first name, last name, or email address. If this isn’t possible for your identity provider, it can be discussed when you work with our integration team.

We have two general methods for SAML integrations for our academic customers:

  1. Multilateral SAML: We’re a member of InCommon and export our SP metadata through eduGAIN to numerous associated federations. This allows for easy SSO setup and management for the SSO integration. The entityID of our multilateral service provider is https://api.oreilly.com/samlsp.
  2. Bilateral SAML: Metadata is externally exchanged and manually managed. This does require some manual work by the IT staff on both sides of the integration.

Have a problem or question? Reach out.

For issues and support regarding your O’Reilly account, please contact your account admin directly or email the customer support team at