@kapa.ai when developing a connector with connector builder, ouath2.0 + profile assertion the scope parameter is not passed into the header's call. the assertion is created correctly but the scope is not passed in order to get the access token

Based on the knowledge sources available, this appears to be a known issue with how Airbyte handles the

scope

parameter in OAuth 2.0 flows. Known Issue: Scope Parameter Not Sent Correctly There is a reported bug where the OAuth authentication flow sends the scope parameter as

"scopes"

instead of

"scope"

(as required by RFC 6749), which causes failures with some third-party APIs. [GitHub Issue] The root cause was identified as the parameter name being hardcoded in the CDK's

AbstractOauth2Authenticator

. [GitHub Issue] Workarounds 1. Use the scope_key Override (Declarative OAuth) If you're using the Declarative OAuth Connector Specification, you can use the

scope_key

optional field to override the parameter name sent to the provider. [OAuth Configuration Fields] 2. Pass Scope as a Query Parameter in the Consent/Token URL You can explicitly include the scope in your

consent_url

or

access_token_url

using the

{{scope_value}}

placeholder, and define the

scope

field separately:

oauth_connector_input_specification:
  consent_url: >-
    https://yourconnectorservice.com/oauth/consent?client_id={{client_id_value}}&redirect_uri={{ redirect_uri_value }}&state={{ state_value }}&scope={{scope_value}}
  access_token_url: >-
    https://yourconnectorservice.com/oauth/token?client_id={{client_id_value}}&client_secret={{client_secret_value}}&code={{auth_code_value}}
  scope: my_scope_A:read,my_scope_B:read

[Scopes as Query Parameter] 3. Use access_token_params for the Token Exchange Step You can inject the scope as a custom query parameter during the token exchange step using the

access_token_params

optional field. [OAuth Configuration Fields] Regarding your specific combination of OAuth 2.0 + Profile Assertion, the knowledge sources do not contain enough detail about how the scope interacts specifically with the Profile Assertion flow to give a more targeted answer. I'd recommend trying the workarounds above and, if the issue persists, filing a bug report on the Airbyte GitHub repository. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

for the api i am having the scope must be in the body @kapa.ai

Based on the knowledge sources, you can use the

access_token_params

property to include parameters (like

scope

) in the body of the token exchange request, rather than as part of the URL. Here's how to configure it:

oauth_connector_input_specification:
  consent_url: >-
    https://yourconnectorservice.com/oauth/consent?client_id={{client_id_value}}&redirect_uri={{
    redirect_uri_value }}&state={{ state_value }}
  access_token_url: >-
    https://yourconnectorservice.com/oauth/token
  access_token_params:
    client_id: "{{ client_id_value }}"
    client_secret: "{{ client_secret_value }}"
    redirect_uri: "{{ redirect_uri_value }}"

When

access_token_params

is used, the parameters are JSON-encoded and included in the body of the outgoing request, instead of being appended to the

access_token_url

. [JSON-encoded params] You can add your

scope

value to the

access_token_params

block as well:

access_token_params:
  client_id: "{{ client_id_value }}"
  client_secret: "{{ client_secret_value }}"
  redirect_uri: "{{ redirect_uri_value }}"
  scope: "your_scope_here"

In the Connector Builder UI, this corresponds to the "Access Token Query Params (Json Encoded)" optional field under the OAuth 2.0 configuration. [Connector Builder OAuth] > Note: The knowledge sources do not explicitly cover how

scope

interacts with a Profile Assertion flow specifically, so if you encounter issues beyond the scope parameter placement, you may need to file a bug report or seek further support from the Airbyte community. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

there is no more Access Token Query Params (Json Encoded)" option only Access Token Value and Access Token Property Name but this is i think for getting the access token @kapa.ai

You're right to question that. Looking at the knowledge sources more carefully, the "Access Token Query Params (Json Encoded)" option is specifically part of the Declarative OAuth Connector Specification flow (when that toggle is enabled), not the legacy OAuth 2.0 configuration. [Connector Builder OAuth] The fields you're seeing (Access Token Value and Access Token Property Name) are part of the standard/legacy OAuth 2.0 configuration options in the Connector Builder UI. [Configuration Options] To get access to Access Token Query Params (Json Encoded), you need to enable the "Declarative OAuth Connector Specification" toggle in the Connector Builder UI. Once enabled, you'll have access to the full set of declarative OAuth options, including: • Access Token Query Params (Json Encoded) — to inject scope (and other params) in the body of the token request • Scopes Key Override — to customize the parameter name used for scope • Client ID/Secret Key Overrides, etc. [Connector Builder OAuth] However, the knowledge sources do not contain enough detail about how Profile Assertion interacts with the Declarative OAuth Specification toggle specifically, so I'd recommend checking whether enabling Declarative OAuth is compatible with your Profile Assertion setup, or reaching out to the Airbyte community for further guidance. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

it's still not working, scope is not transmitted. even after adding it to the Access Token Query Params (Json Encoded) @kapa.ai

I'm sorry to hear the scope is still not being transmitted. Based on the knowledge sources, I can confirm this is a known bug in Airbyte's OAuth implementation. Known Bug The scope parameter is hardcoded to be sent as

"scopes"

instead of

"scope"

in the CDK's

AbstractOauth2Authenticator

, which causes failures with APIs that strictly follow RFC 6749. [GitHub Issue] A contributor noted that a fix was planned but the issue was ultimately closed as stale without a confirmed resolution. Best Available Workaround The workaround mentioned in the GitHub issue is to pass the scope explicitly as a query parameter in the consent URL using the

{{scope_value}}

placeholder, combined with defining the

scope

field:

oauth_connector_input_specification:
  consent_url: >-
    https://yourconnectorservice.com/oauth/consent?client_id={{client_id_value}}&redirect_uri={{ redirect_uri_value }}&state={{ state_value }}&scope={{scope_value}}
  access_token_url: >-
    https://yourconnectorservice.com/oauth/token?client_id={{client_id_value}}&client_secret={{client_secret_value}}&code={{auth_code_value}}
  scope: my_scope_A:read,my_scope_B:read

[Scopes as Query Parameter] However, since your API requires the scope in the body specifically, the knowledge sources do not contain enough information to confirm a fully working solution for that exact requirement given the known bug. I'd recommend: 1. Filing or upvoting a bug report on the Airbyte GitHub repository to get this prioritized. 2. Reaching out to the Airbyte community (Slack or GitHub Discussions) for more targeted support on this specific combination of body-based scope + Profile Assertion flow. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

this is what i have and still nothing.. access_token_params: scope: core:*:* datahub:*:* datasets:*:* reporting:*:* @kapa.ai

I can see you've added the

scope

to

access_token_params

, which is the correct approach based on the documentation. Unfortunately, the knowledge sources do not contain enough information to explain why this specific configuration is still not transmitting the scope correctly in your case. What I can confirm from the knowledge sources is: 1. The

access_token_params

property is intended to send JSON-encoded parameters in the body of the token request. [JSON-encoded params] 2. There is a known bug where the scope parameter may be sent as

"scopes"

instead of

"scope"

at the CDK level, which could be interfering even when you explicitly set it via

access_token_params

. [GitHub Issue] Given that the knowledge sources don't provide a confirmed fix for this specific scenario (body-based scope with Profile Assertion), I'd strongly recommend: • Opening a new GitHub issue at github.com/airbytehq/airbyte/issues with your exact YAML configuration and the API's expected request format, so the Airbyte engineering team can investigate. • Joining the Airbyte Slack community for real-time support from contributors who may have encountered the same issue. The knowledge sources available to me don't go deep enough into the internals of how

access_token_params

interacts with the Profile Assertion flow to give you a definitive fix. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.