OAuth 2.0

OAuth 2.0 Grant Types Explained

eMOBIQ AI supports OAuth 2.0 as a secure and flexible authentication method for connecting to external APIs. OAuth 2.0 defines several grant types, each suited to different application architectures and security requirements. Understanding which grant type to use ensures your integration is both functional and compliant with the external service’s security policies.

Below, we explain the different OAuth 2.0 grant types supported in eMOBIQ AI, when to use them, and how they work.

Before You Begin: Configure Your OAuth Provider

To use OAuth 2.0 in eMOBIQ AI, you must first register your application with the external API provider (e.g., Google, Microsoft Azure, Auth0, or your own OAuth server).

During registration, you’ll typically need to provide:

• Redirect (Callback) URL: Use the Callback URL shown in your eMOBIQ AI OAuth configuration (e.g., https://api.emobiq.com/oauth/callback or a custom one if supported).

• Application Type: Select the correct type (e.g., “Web Application” for Authorization Code, “Confidential Client” if using Client Secret).

• Allowed Grant Types: Ensure the provider has enabled the grant type you intend to use (e.g., Authorization Code + PKCE, Client Credentials, etc.).

• Scopes: Request only the permissions your integration needs.

• Client Authentication:

Send as Basic Auth Header: client_id & secret will be base-64 encoded and sent as HTTP header ("Authorization": "Basic XXXXXX")

Send client credentials in body: client_id & secret will be on response body instead, mixing with the rest of the params (scopes, etc)

Without this external setup, eMOBIQ AI cannot complete the OAuth handshake—even if all fields are filled correctly.

Configuring OAuth 2.0 in eMOBIQ AI

When setting up an External API connection:

1. Select OAuth 2.0 as the authentication type

2. Choose the appropriate grant type from the dropdown

3. Fill in the required fields (URLs, credentials, etc.)

4. (Optional but recommended) Add Authentication Instructions to guide the AI on how to include the token in requests (e.g., Authorization: Bearer <token>)

1. Password Credentials

Use Case: Your application is highly trusted (e.g., a first-party native app), and you can securely collect the user’s username and password

How It Works

• The client (your eMOBIQ AI app) sends the user’s username and password directly to the authorization server

• In return, the server issues an access token (and optionally a refresh token)

• This token is then used to authenticate subsequent API requests

Required Configuration in eMOBIQ AI

• Access Token URL – The endpoint where credentials are exchanged for a token

• Username and Password – Provided by the end user or stored securely

• Client ID and Client Secret – May be required depending on the API provider

2. Client Credentials

Use Case: Your application needs to access its own resources (not user-specific data), such as backend services or machine-to-machine communication

How It Works

• The client authenticates as itself using its Client ID and Client Secret

• The authorization server returns an access token scoped to the client’s permissions

• No user interaction is involved—ideal for automated or server-side workflows

Required Configuration in eMOBIQ AI

• Access Token URL

• Client ID

• Client Secret

3. Authorization Code

Use Case: Building a web application that accesses user data with their explicit consent (e.g., integrating with Google, Microsoft, or Salesforce)

How It Works

1. The user is redirected to the authorization server to log in and approve permissions

2. Upon approval, the server redirects back to your app with an authorization code

3. Your app exchanges this code for an access token (and often a refresh token) via a backend call

Required Configuration in eMOBIQ AI

• Authorization URL – Where users are sent to log in and consent

• Access Token URL – Where the authorization code is exchanged for a token

• Client ID and Client Secret

• Callback (Redirect) URL – Must match a URL pre-registered with the API provider

eMOBIQ AI acts as a confidential client, meaning it can securely store the Client Secret. The authorization code exchange happens server-to-server — no browser or user agent is involved. You do not need to use PKCE unless the provider explicitly requires it (e.g., for public clients). However, if your provider mandates PKCE even for confidential clients (some do, like certain OpenID Connect setups), use the “Authorization Code with PKCE” option.

4. Authorization Code with PKCE (Proof Key for Code Exchange)

Use Case: Use this flow only if your OAuth provider requires PKCE — even for server-side applications (e.g., some identity providers enforce it universally). While PKCE was originally designed for public clients (like SPAs or mobile apps), some modern providers mandate it for all Authorization Code flows.

How It Works

• Similar to the standard Authorization Code flow, but adds a cryptographic challenge to prevent code interception attacks

• Before redirecting the user, the client generates a code verifier and its hashed version (code challenge)

• The code challenge is sent during authorization

• When exchanging the code for a token, the client sends the original code verifier—the server validates it against the stored challenge

Required Configuration in eMOBIQ AI

• Authorization URL

• Access Token URL

• Client ID (Client Secret is not required and often omitted)

• Callback URL

• PKCE Mode – Typically SHA-256 for strong security. Choose the algorithm used to generate the code challenge:

  • SHA-256 (Recommended) → Uses cryptographic hashing for maximum security.

  • Plain → Sends the code verifier directly (less secure, only for legacy systems).