https://linen.dev logo
Join Slack
Powered by
Hey, i have been banging my head with this for a w...
# ask-community-for-troubleshooting
o
Hey, i have been banging my head with this for a while now. Quite annoyingly i was not able to set up a connector to Fortnox, problem seems to be due to the Self-hosted Airbyte's Connector Builder automatically injecting OAuth UI flows (triggering 
/api/oauth/access_token
redirect loops) even when using 
SessionTokenAuthenticator
or 
BearerAuthenticator
without declarative OAuth enabled, making it impossible to create sources with manual token input for custom connectors that only need token refresh, not full OAuth flows. The connector works fine in the builder area when testing but it is impossible once published to add it as a source due to the problem mentioned above. As anyone encountered this before, and fixed it? Thx
k
Based on the knowledge sources, I can see that you're experiencing an issue that has been reported by other users. Let me explain what's happening and what information is available: ## The Issue Your problem appears to be related to a known issue where Airbyte automatically injects OAuth flows even when you're trying to use simpler authentication methods like 
SessionTokenAuthenticator
or 
BearerAuthenticator
. This is documented in [GitHub Issue #52084](https://github.com/airbytehq/airbyte/issues/52084), where users reported that as of Airbyte 1.4, data sources that could be authorized using OAuth2 no longer allow manual entry of `access_token`/`refresh_token`. According to the discussion in that issue, the problem is that: 1. Airbyte now requires the full OAuth2 flow for certain connectors 2. This requires the Airbyte instance to have a publicly accessible endpoint (
/auth_flow
) 3. Some OAuth2 providers only allow one redirect, making this particularly problematic ## Current Status The good news is that this issue has been acknowledged by the Airbyte team. According to the [GitHub discussion](https://github.com/airbytehq/airbyte/issues/52084), contributors mentioned that they were working on expanding the flexibility of OAuth2 authentication, and that you should still be able to bring your own 
client_id
, 
client_secret
, and tokens. One contributor noted: "I believe there was a reason for not providing the 
access token
option authentication... Generally speaking, I agree that the best approach is to have 
Airbyte-Own OAuth Apps
alongside the ability to switch to the 
Use my credentials
toggle manually." ## Potential Workaround For custom connectors that only need token refresh without the full OAuth flow, you might want to try using the [OAuth 2 without Declarative OAuth Connector Specification](https://docs.airbyte.com/platform/connector-development/connector-builder-ui/authentication#without-declarative-oauth-connector-specification) approach. This legacy method allows you to use an existing access token or refresh token to authenticate with the API, which might bypass the automatic OAuth UI injection you're experiencing. However, the knowledge sources don't provide a definitive solution for preventing the OAuth UI injection in Self-Managed Airbyte when using 
SessionTokenAuthenticator
or 
BearerAuthenticator
. The issue appears to be an ongoing concern that the team is working to address. I recommend monitoring the GitHub issue mentioned above for updates, as the team indicated they were reviewing the problem and working on a solution.
o
is there a way then to set up a custom connector just needing client id and secret as inputs and having the authentication managed via the UI on the self hosted instance then? because i have had issues even setting that up @kapa.ai
k
A message from kapa.ai
Based on the knowledge sources, yes, there is a way to set up a custom connector with just client ID and secret, with authentication managed via the UI. Here's what's available: ## For Self-Managed Airbyte According to the [OAuth documentation](https://docs.airbyte.com/platform/using-airbyte/oauth), in Self-Managed Airbyte, you can configure your own client credentials: 1. Register an application on the third-party platform to obtain a Client ID and Client Secret 2. Enter your Client ID and Client Secret into the connector settings in Airbyte 3. Click the authentication button The documentation states that "The complexity of setting up OAuth flows is handled internally by Airbyte. When you set up a new connector, you only need to complete a few steps to use OAuth." ## For Custom Connectors with Declarative OAuth For connector development, you can use [Declarative OAuth 2.0](https://docs.airbyte.com/platform/connector-development/config-based/advanced-topics/oauth), which allows you to implement OAuth authentication flows without writing any code. This approach: - Requires you to provide your own 
client id
and 
client secret
- The configuration is processed and executed by the Airbyte platform on your behalf - Handles the OAuth flow coordination including generating consent URLs, token exchange, and refresh token management The configuration is done through the 
advanced_auth.oauth_config_specification
field in your connector's spec file. ## Important Note However, based on the [GitHub issue discussion](https://github.com/airbytehq/airbyte/issues/52084) you mentioned earlier, there appears to be an ongoing challenge with the OAuth UI injection. One contributor noted that "it requires the AirByte instance to have a publicly accessible endpoint (/auth_flow)," which may be causing issues in your self-hosted setup. The knowledge sources don't provide specific troubleshooting steps for when the OAuth UI setup fails in self-hosted instances. If you're still experiencing issues with the setup, this appears to be part of the broader problem being addressed by the Airbyte team.
o
@kapa.ai the authentication button doesnt work, it always returns an error!
k
A message from kapa.ai
Based on the knowledge sources, I can see that authentication button errors are a known issue, particularly with OAuth in self-hosted Airbyte instances. Here's what the documentation suggests for troubleshooting: ## Common OAuth Authentication Issues According to the [OAuth troubleshooting documentation](https://docs.airbyte.com/platform/using-airbyte/oauth), when OAuth connections fail, it's usually one of these problems: ### 1. Invalid Credentials - Verify that the Client ID and Client Secret are correct - Check for typos or missing configuration steps ### 2. Expired Token - Airbyte handles access tokens and refresh tokens for you - If something goes wrong, try reauthorizing the connector ### 3. Redirect URI Mismatch - Confirm that the redirect URI registered with the third-party platform matches the URI used by Airbyte - Airbyte's user interface provides this URI when you set up a new connector - Make sure you enter this value exactly as shown ## Known Issues Your problem may be related to the broader OAuth issues discussed in the previous conversation. The [GitHub issue #62080](https://github.com/airbytehq/airbyte/issues/62080) documents a case where the Google Analytics 4 connector "behaves differently on Cloud and OSS" with OAuth authentication, where it fails in Airbyte Cloud but succeeds in Airbyte OSS with the same credentials. Additionally, [GitHub issue #67581](https://github.com/airbytehq/airbyte/issues/67581) reported authentication issues after upgrading to version 1.8.5, where users "cannot connect using the client ID and secret." This issue was eventually resolved in version 2.0. Unfortunately, the knowledge sources don't provide specific error messages or detailed troubleshooting steps for when the authentication button consistently returns errors in self-hosted instances. If you're experiencing persistent authentication button failures, this appears to be part of the OAuth implementation challenges in self-hosted environments that the Airbyte team has been working to address.
o
@kapa.ai so basically it just doesnt work..?
k
A message from kapa.ai
Based on the knowledge sources, I need to be careful not to overstate the situation. Here's what the evidence shows: ## OAuth in Self-Managed Airbyte Does Work - But With Limitations According to the [official documentation](https://docs.airbyte.com/platform/using-airbyte/oauth), OAuth is supported in Self-Managed Airbyte. The documentation explicitly states: - "Many Airbyte connectors support OAuth 2.0, enabling secure and seamless integration between Airbyte and third-party APIs" - "OAuth is supported in airgapped instances of Airbyte. Redirects happen in your web browser, not the Airbyte server" ## The Specific Issues You're Encountering However, the knowledge sources do reveal several known problems that align with your experience: 1. Custom Connector OAuth Issues: The [GitHub issue #52684](https://github.com/airbytehq/airbyte/issues/52684) shows that some connectors fail with the error: "Requested OAuth implementation for [connector], but it is not included in the oauth mapping" - indicating that not all connectors have OAuth properly configured 2. Missing UI Fields: [GitHub issue #53158](https://github.com/airbytehq/airbyte/issues/53158) documents cases where "there is no option to specify the Client ID and Client Secret for OAuth authentication" in the UI for certain connectors in OSS 3. Legacy OAuth Implementation: One contributor noted that "The problem is that we have the Legacy OAuth Implementation that prevents the UI from drawing the 
client_id / client_secret
fields correctly" ## The Bottom Line OAuth functionality does work in Self-Managed Airbyte for many connectors, but there are documented issues with: - Custom connectors built in the Connector Builder - Certain connectors that haven't been migrated to the newer Declarative OAuth implementation - UI rendering of OAuth fields in some cases The knowledge sources don't indicate that OAuth is completely broken, but rather that there are specific scenarios (like yours with custom connectors) where it's currently problematic.
o
so again, it doesnt work for custom connector using oauth 2.0 on self hosted instance, that is my point. @kapa.ai
k
A message from kapa.ai
You're correct, and I apologize for not being clear enough. Based on the knowledge sources, OAuth 2.0 for custom connectors in Self-Managed Airbyte has documented issues. ## The Evidence The [GitHub issue #52684](https://github.com/airbytehq/airbyte/issues/52684) specifically documents that custom connectors fail with OAuth in self-hosted instances, showing the error: > "Requested OAuth implementation for [connector], but it is not included in the oauth mapping" Additionally, [GitHub issue #53158](https://github.com/airbytehq/airbyte/issues/53158) confirms that for certain connectors in OSS, "there is no option to specify the Client ID and Client Secret for OAuth authentication" in the UI. ## Recent Developments However, there is one important update: According to the [release notes for version 1.5](https://docs.airbyte.com/release_notes/v-1.5), Declarative OAuth 2.0 was added to the Connector Builder in February 2025. The release notes state: > "If you're building a connector to an API and want to authenticate with OAuth, you can now authenticate directly in the Connector Builder. This simplified flow ensures you can start building connectors to APIs that support OAuth without writing code to authenticate yourself and provide Airbyte with tokens." This suggests that OAuth support for custom connectors in the Connector Builder was specifically added in version 1.5. If you're running an earlier version of Self-Managed Airbyte, this functionality may not be available yet. ## Your Point is Valid You're right that based on the documented issues and your experience, OAuth 2.0 for custom connectors in Self-Managed Airbyte has been problematic, particularly in versions before 1.5. The knowledge sources support your assertion that this functionality has not been working reliably for custom connectors.
o
im on version 2.0.1!!!! @kapa.ai
k
A message from kapa.ai
I understand your frustration. You're on version 2.0.1, which is after the Declarative OAuth 2.0 feature was added to the Connector Builder in version 1.5 (February 2025), and even after version 2.0 was released. ## What the Knowledge Sources Show for Version 2.0+ According to the [release notes for version 2.0](https://docs.airbyte.com/release_notes/v-2.0#better-connector-builder-interface), there were significant changes to the Connector Builder interface: > "OAuth 2.0 flows are now fully supported in the Connector Builder, including in asynchronous streams." The release notes also state that "virtually all the capabilities of YAML mode are available in the UI" and that "Future new features can be available in the UI at release time." ## The Problem Despite these improvements, the knowledge sources don't provide specific troubleshooting steps for when OAuth authentication buttons fail in version 2.0+ for custom connectors in Self-Managed instances. The [GitHub issue #52084](https://github.com/airbytehq/airbyte/issues/52084) discussion mentions that one of the challenges is that OAuth flows require "the AirByte instance to have a publicly accessible endpoint (/auth_flow)," which may be causing the redirect loop issues you described in your original question. ## What I Cannot Find The knowledge sources don't contain: - Specific error messages or solutions for OAuth authentication button failures in version 2.0.1 - Workarounds for the 
/api/oauth/access_token
redirect loop issue you're experiencing - Confirmation that this specific issue has been resolved in version 2.0.1 Given that you're on a current version and still experiencing these issues, this appears to be an unresolved problem that may require direct support from the Airbyte team or filing a new GitHub issue if one doesn't already exist for version 2.0+.
Open in Slack
PreviousNext
Powered by