What is OAuth2.0?

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:

5. Upon user consent, the Authorization Server generates an authorization code and concludes the authentication window.
6. 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.
7. After validating the authorization code, the server responds with a token, and optionally, a refresh token. This token serves for user-authorized requests.
8. Tulip can now execute requests on behalf of users, with the provided token for authorization.

Configuring OAuth

Authentication Types

Tulip supports two OAuth2.0 authentication types: Admin OAuth and Operator OAuth. The key distinction lies in how credentials are shared across users.

• 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.

Digging Deeper

Eager for more insights? Explore these articles:

• OAuth2.0 Configuration and Technical Details
• How To Run A Connector Function in Multiple Environments