What is OAuth2.0?
  • 24 May 2024
  • 4 Minutes to read
  • Contributors

What is OAuth2.0?


Article summary

Exploring OAuth2.0

Welcome to an exploration of OAuth2.0, a powerful yet often misunderstood authentication protocol within the Tulip-verse. In this article, we will unravel the fundamentals, guide you through Tulip's supported authentication flows, demystify the configuration of your initial connector, and share quick tips for a seamless start.

OAuth2.0 can be intricate, and to keep things concise, we've omitted some detailed technical aspects from this article. If you're eager for a deeper dive into Tulip's handling of refresh tokens, scope and audience management, and custom connector configurations, we recommend checking out this in-depth OAuth2.0 technical guide.

Unveiling the Basics

Before delving into the specifics, we suggest acquainting yourself with Environments and gaining an overview of Connector Hosts and their functions.

OAuth2.0 serves as a mechanism for Tulip (the client) to establish its identity with your business systems. Access is granted through a handshake, and Tulip primarily supports the Authorization Code Flow, the most common OAuth flow. Here's a condensed overview of how this flow unfolds:

  1. User initiates the flow by clicking the Test button before saving a Connector.
  2. Tulip communicates with the Authorization server from your OAuth provider, sharing specific parameters such as client identity, scopes (what you're attempting to access), and other relevant details.
  3. The Authorization Server prompts the user to grant access, exemplified below:

  1. Upon user consent, the Authorization Server generates an authorization code and concludes the authentication window.
  2. Armed with an authorization code, Tulip securely requests a token by reaching out to the token endpoint, providing the authorization code, client id, client secret, and additional properties.
  3. After validating the authorization code, the server responds with a token, and optionally, a refresh token. This token serves for user-authorized requests.
  4. Tulip can now execute requests on behalf of users, with the provided token for authorization.

Token Request

Configuring OAuth

On-Prem Services

The Authorize and Token endpoints must be accessible to the cloud for Tulip to execute authentication for connectors

image

Authentication Types

Tulip supports two OAuth2.0 authentication types: OAuth2.0 (Service Account) and OAuth2.0 (User Credentials). The key distinction lies in how credentials are shared across users.

Note

In older Tulip versions OAuth2.0 (Service Account) was called OAuth2 (Admin) and OAuth2.0 (User Credentials) was called OAuth2 (Operator).

  • OAuth2.0 (Service Account): Uses credentials provided during connector testing for all users in the Tulip Player. Ideal for shared credentials across your organization. Admin reauthentication is required if credentials expire.

  • OAuth2.0 (User Credentials): Segments authentication based on the user logged into Tulip Player. If a user hasn't authenticated or authentication expires, the user undergoes the OAuth flow within the Tulip Player.

Authorization Code URL

This is the URL Tulip contacts in step 2 of the authentication code flow. Found in your OAuth provider's API documentation, it typically ends in /auth or /authorize.

Access Token URL

Post Authorization Server response, a request is made to the Access Token URL to obtain a token for authentication. Generally ends in /token.

Client ID and Client Secret

Generated from your OAuth Provider's UI, the Client ID is passed with the initial request for an authentication code. The Client ID and Client Secret accompanies all token requests.

Audience and Scope

Audience specifies the specific assets your user seeks access to, while Scope defines the actions desired on these assets. Both are conveyed during the authorization code request in step 2.

Additional Options

  • Send token request data as JSON: Changes encoding type for the request sent to the token URL. Enabled if needed for specific integrations.

  • Send Authentication Header for refresh request: Adds an extra Header to refresh requests when enabled.

  • Skip User Consent Prompt: Controls the prompt attribute of the Authentication Code request. Disabled sets it to consent, while enabled sets it to login, letting the OAuth provider decide on the login screen to display.

Note

For some integrations, exclude or set the prompt attribute to none. Reach out to support@tulip.co for further functionality.

Digging Deeper

Eager for more insights? Explore these articles:


Was this article helpful?