Configure Microsoft Entra ID to use JWT

JWT with Entra ID

SnapLogic public APIs support JWT authentication. Users can use any IdP (including Microsoft Entra ID) as long as:

  1. The JWT is correctly signed and verifiable via a JWKS endpoint.
  2. The token contains certain claims (fields inside the JWT).

Here is an example which shows a generated token body with the required claims:

{
            "iat": 1746477764,
            "exp": 1746481364,
            "sub": "[email protected]", 
            "aud": "https://elastic.snaplogic.com/api/1/rest/public",
            "iss": "6255cabfb089cfac8f490573",
            "org": "MyEnvironment"
            }
  • iat: Issued-at time (Unix timestamp).
  • exp: Expiration time.
  • sub: The SnapLogic username (user identity).
  • aud: The SnapLogic public API base URL (varies by POD – US, EMEA, UAT, etc.).
  • iss: Issuer ID (configured in SnapLogic).
  • org: SnapLogic org/environment name.

Custom claims

If sub and aud claims cannot be modified in your IdPs to match the expected value and there is a conflict adding the custom claim, you must send these custom claims, depending on the case:

Microsoft Entra does not allow you to set sub and aud for id_token/access_token. So SnapLogic supports custom claims:

  • If you cannot match the default expected values, use: 
    
                        {
                          "snaplogic_aud": "https://elastic.snaplogic.com/api/1/rest/public",
                          "snaplogic_username": "[email protected]",
                          "snaplogic_org": "MyEnvironment"
                        }
    Important:
    • aud and sub can remain with Microsoft’s own values.
    • org is optional if snaplogic_org is present (SnapLogic uses the custom one).

POD and ORG - based configuration

JWT authentication is tied to:

  • POD (e.g., Prod US, EMEA, UAT) – affects the aud (the base URL of SnapLogic public APIs).
Important: For each SnapLogic ORG in each POD that uses JWT auth, the user must have a separate registered app in Microsoft Entra.

Entra-specific behavior

For Microsoft Entra, use the id_token as the Bearer token for public API calls, not the access_token due to the following reasons.

  • Entra’s id_token is easier to shape with the required claims for user identity and custom attributes.
  • The client still retrieves access_token for Graph calls, but SnapLogic uses id_token contents.

Microsoft Entra configuration

Create and register the application in Azure portal
  1. Log in to the Microsoft Azure Portal and go to Microsoft Entra ID.
  2. Choose the correct Tenant.
  3. In the left menu, select App registrations.

  4. Click New registration:

    • Give the app a name.
    • Choose supported account types (single-tenant, multi-tenant, etc., as needed).
    • Set the Redirect URI (Web) (e.g., http://localhost:8000/callback for testing, or your real app URL).
    • After registration, click the app to configure it to view the following details.
      • Client ID (Application ID) – used in token requests.
      • Tenant ID – also used in token URLs.
  5. To create a Client secret, from the app page, in the left navigation panel, select Manage > Certificates & secrets.
Click on Client credentials to add and copy the secret value which goes into the token request.
Important: You can copy the Client secret value only after it is generated. Note that this value is displayed only once, so ensure to copy it securely.

Application ID URI / Expose an API

  1. From the app, select Expose an API.
  2. Here you see or set the Application ID URI.
Important:
  • This Application ID URI becomes the Audience claim aud of the JWT token.
  • It cannot be arbitrary: it usually is either the Client ID or based on your tenant domain, but you cannot just set it to SnapLogic’s URL (https://elastic.snaplogic.com/api/1/rest/public) unless you own and verify that domain in Azure.

  • Because of this, you cannot force aud to equal SnapLogic’s public API URL. Hence SnapLogic uses the snaplogic_aud custom claim.

Add required claims in Entra

  1. In the app, go to Token configuration.
  2. Click Add optional claims.
  3. Choose token type Access and select Audience.
  4. Save.

This ensures aud exists in tokens. SnapLogic, however, uses snaplogic_aud for matching the correct public API, since Entra’s aud is not configurable.

Custom claims for SnapLogic

SnapLogic needs these extra claims:

  • org or snaplogic_org
    • Constant string with the SnapLogic Org name (e.g., MyEnvironment).
  • snaplogic_username
    • SnapLogic username (e.g., [email protected]).
    • Mapped to the relevant Entra user attribute (example: user.userprincipalname).
    • Needed because Entra’s sub cannot be modified.

  • snaplogic_aud

    • Must contain the SnapLogic public API base URL for that POD, e.g.

      https://elastic.snaplogic.com/api/1/rest/public (Prod US; change hostname for EMEA/UAT).

Configure the claims

  1. On the app overview page, click Manage application in local directory (on the right)
  2. Go to Single sign-on.
  3. Under Section 2: Attributes & Claims, click Edit.
    • Optional and custom claims show here.
  4. Click Add new claim for each SnapLogic claim:

    • For snaplogic_aud:

      • Name: snaplogic_aud
      • Source: Attribute
      • Source attribute: a constant string with the SnapLogic API URL for the POD, e.g.

        https://elastic.snaplogic.com/api/1/rest/public

    • For org or snaplogic_org:
      • Name: org or snaplogic_org
      • Source: Attribute
      • Source attribute: constant string with the SnapLogic ORG name (e.g., MyEnvironment).
    • For snaplogic_username:
      • Name: snaplogic_username
      • Source: Attribute
      • Source attribute: the Entra user field that corresponds to the SnapLogic username, e.g.:
        • user.userprincipalname
        • or another appropriate attribute depending on the customer’s mapping.

After this, tokens include the needed SnapLogic claims.

Test the configuration

  1. Perform the Authorization Code OAuth2 flow against Microsoft Entra.
  2. Get access_token, id_token, (optionally refresh_token).
  3. Decode the tokens locally to verify the claims.

Using the token with SnapLogic public APIs

Once you verify the id_token contains the correct SnapLogic-related claims:

  • Use that id_token as Bearer token when calling SnapLogic public APIs, e.g.: 
GET https://elastic.snaplogic.com/api/1/rest/public/... Authorization: Bearer
            <id_token>

SnapLogic does the following

  1. Validate the token signature with the configured JWKS.
  2. Check issuer/iss and org.
  3. Extract:
    • snaplogic_username → SnapLogic user.
    • snaplogic_aud → validate matches the API URL (POD).
    • org/snaplogic_org → SnapLogic org.
  4. Authorize the request.