Issue while using HTTP connector with Azure APP gateway

HI,
we have a setup in azure where our backend api’s are deployed on azure app service and are exposed for external use using app gateway over port 80 and 443.
we have created an http connector with server URL as app gateway URL and authentication type as user credentials, TLS set to true.
user credentials used are client id, client secret and scope from the app registration done on Microsoft Entra on Azure.
when I click Test button on the edit environment page I get Test Passed.

Further when I am creating a function for a post api call.. I am getting following error:
Function Test Error
There was an error while testing the function: [500] OAuthError: no operator token.

My question is when we select user credentials and TLS true with certificate upload what should be the auth type while creating the function?

one thing to note is when I select TLS = true we are uploading a certificate and passphrase.

Could you please help me on this?

Hi, update on above question, we are using http connector with user credentials authentication to call REST API’s. The setup is working but sometimes we are getting above error, the connector function works for some people and gives error for others. I just wanted to check is this because token expiration.
default_expires_in(s) = 86400=24h.
there is a mentioned that if expires_in is not mentioned then default_expires_in will be used for token expiry date, but where to give expires_in is not given anywhere. could you please guide?

Hi @p.bhagwan.gaikwad , apologies that you’re encountering challenges here. Have you tried dropping in on Tulip Office Hours?

https://university.tulip.co/new-user-office-hours

@OlgaStroilova I just checked the office hours the immediate one is on 27 May. that’s kind of delayed for me. is there any other way?

We have a long weekend here with Memorial Day, and are back on Tuesday which is the 27th.

You could also consider reaching out to the Tulip Support team or escalating to your Tulip representative to get faster attention if it’s critical for a deployment.

In the meantime, here are some troubleshooting steps. Likely you’ve probably done some or most of them, but I’m including them all just in case a detail in one of the early steps may help. Short version is yes, this may be related to expiry date – or to token refresh. I’ll start with instructions on how to set default_expires_in, and then share the more general troubleshooting steps. If resetting default_expires_in (Step 3 and detailed instructions below) doesn’t work, try Step 4 - debugging Token storage and refresh.

This is a long post but hopefully it’s helpful until the Office Hour.


Setting the default_expires_in in Your HTTP Connector

There are two ways to configure the token expiration in your HTTP connector:

Method 1: Via the Advanced Configuration Settings

  1. Navigate to your HTTP connector configuration page
  2. Scroll down to the bottom where you’ll find the “Advanced Configuration” section (or a similar section, depending on your Tulip version)
  3. Look for a “Custom Configuration” or “Additional Settings” field that accepts JSON input
  4. Add the following JSON configuration:
{
  "default_expires_in": 86400
}

(Where 86400 is the number of seconds for token expiration - 24 hours in this case – this value is what you change to make the expiry longer if needed)

Method 2: In the Authorization Settings

In newer versions of Tulip:

  1. Open your HTTP connector configuration
  2. In the Authentication section where you’ve selected “User Credentials”
  3. After entering your Client ID, Client Secret, and Scope
  4. Look for an “Advanced” or “Token Settings” option (may need to click to expand)
  5. There should be a field labeled “Token Expiration Time” or “Default Expires In”
  6. Enter the value in seconds (e.g., 86400 for 24 hours or a larger value if needed)

Important Notes:

  1. If you don’t see these options in your current version, you may need to update to a more recent version of Tulip that includes this feature.
  2. For the specific error you’re encountering with Azure authentication, setting a longer token expiration time (like 604800 seconds for 7 days) might help reduce the frequency of the “no operator token” errors.
  3. Make sure you add the offline_access scope to your OAuth configuration if you haven’t already, as this is necessary for Azure to provide refresh tokens.
  4. After making these changes, you’ll need to re-authenticate the connector to apply the new token expiration settings.

If you don’t see these options in your current version of Tulip, please consult Tulip Support or your administrator to check if this feature is available in your current version and how to access it.


Broader Troubleshooting Guide for the “OAuthError: no operator token” issue

Step 1: Check Your Authentication Configuration

  1. Verify your HTTP connector is configured with:
  • Authentication type: User credentials (OAuth2)
  • TLS: true (with your certificate correctly uploaded)
  • Client ID and Client Secret from your Azure App Registration
  • Appropriate scope (e.g., “offline_access” to get refresh tokens)

^^ please double check both OAuth2 and offline_access here

Step 2: Double check the OAuth Modes in Tulip

Tulip supports several OAuth authentication modes:

  • OAuth 2 (Admin) - Tokens are stored at the connector level, managed by admins
  • OAuth 2 (Operator) - Tokens are associated with individual operators
  • Bearer - For static tokens

For your setup, ensure you’re using the appropriate mode based on your requirements.

^^ My guess is you are, this is just a next quick sanity check

Step 3: Address Token Expiration Issues

The intermittent nature of your issue strongly suggests token expiration problems. When you create a function:

  1. Set default_expires_in in your connector configuration:
  • You can add a setting in your connector configuration to set the default token expiration time
  • Recent updates to Tulip allow defining a default expiry period for API tokens for OAuth connectors
  1. For the “no operator token” error specifically:
  • This typically happens when an operator tries to use a connector function but doesn’t have a valid token
  • Ensure all operators have authenticated to the connector before using functions
  • If using Operator mode, each operator needs to authenticate separately

^^ See deep dive section above for how to set this up in your connector settings

Step 4: Debug Token Storage and Refresh

The error suggests the token isn’t available when needed. To troubleshoot:

  1. Check if your Azure Entra app registration is correctly configured to provide refresh tokens
  2. Verify your connector is properly storing and refreshing tokens
  3. If tokens expire frequently, the refresh process might be failing

^^ For this please consult Azure Entra documentation. I’ve also included some ideas on how to do this in the next post below, but Azure Entra docs for your version are the source of truth here.

Step 5: Check Function Authentication Settings

When creating your POST API function:

  1. Ensure the authentication method in the function matches your connector settings
  2. For OAuth authentication, your function should use:
  • Authorization headers automatically populated by the connector
  • Ensure you’re not trying to manually include authentication headers

Additional Recommendations:

  1. Token Expiration Settings:
  • In your Azure Entra app registration, check the token lifetime policies
  • You can adjust token lifetimes in Azure to be longer if needed
  1. Function Configuration:
  • When creating your function, ensure you’re not overriding the authentication method
  1. TLS Certificate:
  • Since you’re uploading a certificate with a passphrase, ensure it’s in the correct format
  • The certificate should be properly recognized by Tulip

If the issue persists, specific logs from when the error occurs would be helpful for further troubleshooting. In many cases like this, token synchronization between Tulip and Azure can be the root cause of intermittent issues.

I’ll share some additional information on Step 4 above. Please note that this information is about a third-party solution (Azure) and may not be accurate to your version.

Please consult the documentation for your version of Azure for most up-to-date information.

Checking Azure Entra App Registration for Refresh Token Configuration

1. Verify the ‘offline_access’ Scope is Configured

The most important requirement for receiving refresh tokens from Azure Entra is ensuring the offline_access scope is included in your OAuth configuration:

  1. Sign in to the Azure Portal
  2. Navigate to Microsoft Entra ID (formerly Azure Active Directory)
  3. Go to App registrations
  4. Select your application from the list
  5. Navigate to API permissions
  6. Check if offline_access permission is in the list of configured permissions
  • If not, click Add a permission
  • Select Microsoft Graph
  • Choose Delegated permissions
  • Search for and select offline_access
  • Click Add permissions
  1. Don’t forget to click Grant admin consent if required for your organization

2. Check Token Configuration in App Authentication Settings

  1. In your app registration, go to Authentication
  2. Verify the following settings:
  • Under Implicit grant and hybrid flows, ensure appropriate options are selected
  • Check that the correct redirect URIs are configured
  • Under Advanced settings, ensure Allow public client flows is set appropriately for your application type

3. Configure Token Lifetime Policy (Optional)

If you need to customize token lifetimes:

  1. Go to Microsoft Entra ID
  2. Navigate to Security > Authentication methods > Token lifetimes
  3. You can create a custom policy to set refresh token lifetimes
  • Note: This requires Azure AD Premium

4. Verify Client Secret Hasn’t Expired

  1. In your app registration, go to Certificates & secrets
  2. Check the expiration date of your client secret
  3. If expired or close to expiring, create a new secret and update it in your Tulip connector

5. Test Token Acquisition with Microsoft’s OAuth Debug Tools

You can verify your app is correctly configured to provide refresh tokens by:

  1. Using the Microsoft OAuth 2.0 Playground
  2. Or testing with Postman using OAuth 2.0 authentication

When making a token request, ensure your request includes:

scope=offline_access [other required scopes]

In the token response, verify that a refresh_token field is included, which confirms your app is properly configured to provide refresh tokens.

6. Verify Proper Consent Has Been Given

Ensure that:

  1. Users have provided consent to the application
  2. If your app uses application permissions (rather than delegated), an admin has granted consent

Once confirmed, you can update your connector with the proper configuration as discussed earlier.

Hi @OlgaStroilova, thank you so much for the troubleshooting steps! Will try those until the office hours are back on 27th.

Happy long weekend to you!!

1 Like