AzureNewbie1 explains their attempts to obtain an OAuth2 access token for the iLevel API using Azure Data Factory, highlighting issues with client_id/client_secret usage and missing Authorization headers.

Troubleshooting OAuth2 API Token Retrieval with Azure Data Factory

AzureNewbie1 has been tasked with integrating third-party iLevel data into SQL Server, using Azure Data Factory (ADF) Pipelines to automate the process. The iLevel platform requires OAuth2 token-based API authentication, using a client_id and client_secret. Here’s a breakdown of their approach, issues encountered, and actionable suggestions.

Problem Context

  • Goal: Acquire an access token via OAuth2 from the iLevel API for downstream data extraction.
  • Integration Tool: Azure Data Factory (ADF) Pipelines
  • Credential Setup: client_id and client_secret generated in iLevel for both individual (‘Joe’) and team (‘Data team’) accounts. Values stored securely for use.

Configured Steps so Far

  1. Credentials: Generated from iLevel, stored for reference.
  2. ADF Login: Using ‘Joe Admin’ account for ADF development.
  3. Linked Service: Created toward iLevel Base URL. ‘Test connection’ succeeded, confirming network connectivity.
  4. Dataset: Configured based on online guidance, but possibly incorrect.
  5. Pipeline: Contains a ‘Web’ activity to request a token and a ‘Set variable’ activity to store the token.

Web Activity Details

  • URL: Points to iLevel’s token endpoint (different from the API data endpoint).
  • Body: Contains client_id and client_secret (potential formatting issues noted, especially regarding quote usage).
  • Headers: Not supplying an Authorization header, even though iLevel documentation suggests it’s required. Also, uncertainty around Content-Type.
  • Error: Debug run reports ‘invalid client_id or client_secret’, despite using newly-generated values.

Analysis & Recommendations

1. Check OAuth2 Flow Type

  • Confirm that iLevel expects the Client Credentials grant (most common for server-to-server API calls).

2. Body Formatting

  • Usually, the OAuth2 token endpoint expects parameters as application/x-www-form-urlencoded (not JSON or other format).

  • Example body:

      grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET
  • No need to wrap values in single or double quotes.

3. Required Headers

  • Content-Type: Must be application/x-www-form-urlencoded
  • Authorization: Unless iLevel specifically requires a Basic Auth header, you usually do not need it for client credentials.
    • If required: The header should look like Authorization: Basic <base64(client_id:client_secret)>
    • To generate: base64-encode the string client_id:client_secret (no spaces), then prepend with Basic .
  • Check iLevel docs closely for explicit Auth header requirements.

4. Using ADF Web Activity

  • In Web activity:
    • Method: POST
    • URL: Token endpoint
    • Body: As shown above
    • Headers: At minimum, set Content-Type to application/x-www-form-urlencoded. Add Authorization only if docs specify it.

5. Credentials

  • Ensure no accidental whitespace/copy-paste errors in client_id or client_secret.
  • Verify the iLevel-generated IDs are active and permissions are correct for API access.

6. Linked Service vs. Pipeline Auth

  • The Linked Service is not used for token requests—ensure all auth for the token call is explicit in the Web activity.

7. Storing the Token

  • The ‘Set variable’ activity should parse the JSON response using @activity('Web1').output.access_token (modify ‘Web1’ for actual activity name).

Common Pitfall Checks

  • Values should NOT be in quotes in the POST body unless required by the API.
  • Double-check if the team account’s credentials are meant for API access or for UI login only.
  • If the API expects an audience or additional parameters, add them as needed.

Example ADF Web Activity Configuration

  • Method: POST
  • URL: https://ilevel.api/token (replace with actual)
  • Headers:
    • Content-Type: application/x-www-form-urlencoded
    • If required: Authorization: Basic <base64encoded>

  • Body:

      grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET

Next Steps

  1. Review iLevel API documentation for the exact example of a working token request.
  2. Adjust your ADF ‘Web’ activity to match the required headers/body exactly.
  3. Remove unnecessary quotes; adhere to form encoding.
  4. Run the pipeline and check for a successful response—should contain access_token in JSON.

If the above still fails, share a sanitized copy of the full error message and (if possible) a snippet of the iLevel documentation on token acquisition.

This post appeared first on “Microsoft Tech Community”. Read the entire article here