CCF Data Connector - Pass Generated Access Token from POST API to Subsequent GET API in Azure CCP Connector

Question

CCF Data Connector - Pass Generated Access Token from POST API to Subsequent GET API in Azure CCP Connector

Fenil Savani 0

We are developing a CCP connector in Azure and are facing an issue with API authentication flow implementation.

Scenario

The first API endpoint is a POST request used to generate an access_token.

This API requires a secret key to be passed in the request body
It returns an access_token in the response

The second API endpoint is a GET request used to fetch data.

This API requires the generated access_token to be passed in the request header
Header format:
Key: Authorization
Value: <generated_access_token>

Current Approach

We are trying to implement this using Auth Type: API Key.
Using this approach, we are able to successfully generate the access_token from the first API.

Issue Faced

The issue appears to be that the authentication configuration (auth) used for generating the access token in the first API call is also being applied to the second API request.
As a result, the second GET API request is also expecting the API key (secret key) in the request body, which is incorrect and causes the API call to fail.
The second API should only use the generated access_token in the request header and should not reuse the original API key authentication configuration.

Clarification Required We would like to understand:

How can we configure the connector so that the token generated from the POST API endpoint is used in the subsequent GET API request?
Specifically, how can we pass the generated access_token in the Authorization header for the second API request, while the first API uses the secret key in the request body?

Please help us understand the correct approach for handling this authentication flow in Azure CCP Data Connector development.

Rukmini 42,515 Reputation points Microsoft External Staff Moderator

2026-05-13T13:23:36.5366667+00:00
Hey Fenil, it looks like you’re running into the fact that “Auth Type: API Key” applies the same key to every request in your connector, so your GET is still expecting the secret in the body. What you actually want is a two-step flow:

POST to your token endpoint, passing the secret in the body

GET your data endpoint, putting the just-issued token in an Authorization header

In the Codeless Connector Framework you do that by defining two requests in your connection rules, each with its own auth block, for example:

{ "connectionRules": { "authentication": { "type": "None" }, "requests": [ { "name": "FetchAccessToken", "method": "POST", "uri": "https://api.yoursystem.com/oauth/token", "body": { "secretKey": "{{parameters.YourSecretKey}}" }, "auth": { "type": "None" }, "responseProcessingRules": [ { "outputDataName": "accessToken", "path": "access_token" } ] }, { "name": "GetData", "method": "GET", "uri": "https://api.yoursystem.com/data", "auth": { "type": "None" }, "headers": { "Authorization": "Bearer {{accessToken}}" } } ] } }

Key points:

• Give each request its own auth block. If you leave the top‐level auth set to “API Key,” it will be applied to everything.

• On the token‐fetch call, treat the secret as just another field in body (or use an API-key auth there if you like).

• In responseProcessingRules, pull access_token out and stash it in a variable (here called accessToken).

• On the GET, set auth back to None and hand-craft your Authorization: Bearer {{accessToken}} header.

That way your POST only ever sees the secret in the body, and your GET only ever sees the bearer token in its header.

Hope that clears it up!

Reference docs:

• Create a codeless connector for Microsoft Sentinel – secure inputs & CCF patterns

https://learn.microsoft.com/azure/sentinel/create-codeless-connector

• Troubleshooting access token generation in ADF

https://learn.microsoft.com/en-us/azure/data-factory/control-flow-web-activity#web-activity

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.
Rukmini 42,515 Reputation points Microsoft External Staff Moderator

2026-05-14T09:31:56.9466667+00:00

Hello Fenil Savani

Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Fenil Savani 0 Reputation points

2026-05-14T10:47:20.6133333+00:00

Hello Rukmini,
Some of the keys in your example are not supported in CCP connector definition files referred from official docs and tried as well. Also, I am facing deployment error while using auth type value "None".
Fenil Savani 0 Reputation points

2026-05-15T07:13:28.4466667+00:00

Hello Rukmini Konstantinos Lianos,

We have tried the many possible solutions along with suggested by you, but it is not working for our specific use case and authentication scenario.

We would request a concrete and confirmed solution for this authentication flow, along with proper documentation or a working example/reference that specifically supports our use case to move forward on CCP connector.

Since the customer is actively waiting for the Data Connector implementation we are moving forward with Azure Function App based connector with Log Ingestion API.
Rukmini 42,515 Reputation points Microsoft External Staff Moderator

2026-05-15T09:33:49.4766667+00:00
Hello Fenil Savani

Thank you for the update.

As of now, For this authentication flow, there isn't an officially recognized CCP/CCF pattern where:

The second GET API dynamically consumes the produced token in the Authorization header without reusing the initial auth setup, while the first POST API creates a token using a secret in the request body.

This request-level auth separation does not seem to be supported natively by CCF authentication, which is currently implemented at the connector level.

Given this restriction, the suggested and dependable course of action for this customer scenario is to proceed with Azure Function App + Log Ingestion API.

Let me know if any further queries - feel free to reach out!
Rukmini 42,515 Reputation points Microsoft External Staff Moderator

2026-05-18T10:55:19.9033333+00:00

Hello Fenil Savani

Following up to see if the above provided information was helpful. If you have any further queries do let us know.

1 answer

Your answer

Rukmini 42,515 Reputation points Microsoft External Staff Moderator

2026-05-14T09:31:56.9466667+00:00

Hello Fenil Savani

Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Fenil Savani 0 Reputation points

2026-05-14T10:47:20.6133333+00:00

Hello Rukmini,
Some of the keys in your example are not supported in CCP connector definition files referred from official docs and tried as well. Also, I am facing deployment error while using auth type value "None".
Fenil Savani 0 Reputation points

2026-05-15T07:13:28.4466667+00:00

Hello Rukmini Konstantinos Lianos,

We have tried the many possible solutions along with suggested by you, but it is not working for our specific use case and authentication scenario.

We would request a concrete and confirmed solution for this authentication flow, along with proper documentation or a working example/reference that specifically supports our use case to move forward on CCP connector.

Since the customer is actively waiting for the Data Connector implementation we are moving forward with Azure Function App based connector with Log Ingestion API.
Rukmini 42,515 Reputation points Microsoft External Staff Moderator

2026-05-15T09:33:49.4766667+00:00

Hello Fenil Savani

Thank you for the update.

As of now, For this authentication flow, there isn't an officially recognized CCP/CCF pattern where:

The second GET API dynamically consumes the produced token in the Authorization header without reusing the initial auth setup, while the first POST API creates a token using a secret in the request body.

This request-level auth separation does not seem to be supported natively by CCF authentication, which is currently implemented at the connector level.

Given this restriction, the suggested and dependable course of action for this customer scenario is to proceed with Azure Function App + Log Ingestion API.

Let me know if any further queries - feel free to reach out!
Rukmini 42,515 Reputation points Microsoft External Staff Moderator

2026-05-18T10:55:19.9033333+00:00

Hello Fenil Savani

Following up to see if the above provided information was helpful. If you have any further queries do let us know.

Answer 1

Helo @Fenil Savani ,

Based on the described authentication flow, this does not appear to be a standard API Key authentication scenario.

The source API is using a two-step authentication process:

The first API call is a POST request used only to generate an access_token.

The second API call is a GET request used to fetch data, and it should use only the generated access_token in the Authorization header.

Therefore, the secret key should only be used during the first token-generation request. It should not be reused or applied to the second GET request.

The expected behavior should be:

POST /token

Body: secret_key

Response:

access_token

Then:

GET /data

Authorization: <generated_access_token>

The issue with using Auth Type: API Key is that the API key configuration may be treated as the main authentication method for the connector. As a result, the same authentication configuration can be applied to the following API calls as well. This is why the second GET request appears to expect the original secret key again, which is not the desired behavior.

The correct approach is to treat this as a token-based authentication flow, not as a simple API Key flow.

For Azure CCP Data Connector development, the recommended approach should be:

Use a supported token-based authentication method, such as OAuth2 or JwtToken, if the API can support a standard token flow.

Configure the connector so that it first calls the token endpoint, extracts the access_token from the response, and then uses that token in the Authorization header for the data collection request.

If the API requires a custom secret key in the POST body and this cannot be mapped to the supported CCP authentication types, then a middleware component may be required.

In that case, an Azure Function, Logic App, or similar service can handle the custom authentication flow. The middleware would generate the token, call the data API with the correct Authorization header, and then send the collected logs to Microsoft Sentinel.

So, the key point is that the second GET request should not inherit the original API Key authentication configuration. It should only use the generated access_token.

In summary, the current API Key approach is likely not suitable for this use case unless CCP supports separating the token-generation request from the data-collection request. The best next step is to confirm whether the API can support a standard OAuth2 client credentials or JwtToken flow. If not, a middleware-based implementation would be the safest and cleanest approach.

Fenil Savani 0 Reputation points

2026-05-14T10:57:21.76+00:00

Hello Konstantinos Lianos,

We are successfully able to generate the access token using the first POST API endpoint with auth type API Key.

Our concern is that the authentication configuration defined for the first POST API request (access token generator) appears to also be getting applied to the second GET API endpoint.

What we need is guidance on how to pass the generated access token in the second GET API request using the Authorization header, instead of reusing the authentication configuration of the first API request.

Share via

CCF Data Connector - Pass Generated Access Token from POST API to Subsequent GET API in Azure CCP Connector

1 answer

Your answer