Infor Authentication: IFS OAuth 2.0, ION API Gateway, and Service Accounts

TL;DR

• Bottom line: Infor CloudSuite authentication flows through Infor Federated Services (IFS) as the identity/claims provider and the ION API Gateway as the OAuth 2.0 authorization server. For server-to-server integrations, use the Resource Owner grant with a service account; for web apps, use Authorization Code grant; for Ming.le-embedded apps, use SAML Bearer grant.
• Key limit: Access tokens expire after ~2 hours; refresh tokens are NOT issued by default (must be enabled per-app), rotate every ~8 hours when enabled, and auto-invalidate after 30 days idle.
• Watch out for: The .ionapi credentials file contains four separate credentials for backend services (ClientID, ClientSecret, saak, sask) -- losing any one breaks authentication. Unlike most OAuth 2.0 implementations, Infor requires all four for the Resource Owner grant.
• Best for: Any application integrating with Infor CloudSuite products (M3, LN, CloudSuite Industrial, Distribution, Fashion) via the ION API Gateway.
• Authentication: OAuth 2.0 via IFS (Infor Federated Services). Four grant types: Authorization Code, Implicit, Resource Owner Password (backend service), SAML Bearer (Ming.le SSO). All API calls require a Bearer token issued by the ION API Gateway.

System Profile

This card covers authentication for all Infor CloudSuite products that use Infor OS and the ION API Gateway as their integration platform. This includes CloudSuite Industrial (SyteLine), CloudSuite Distribution, CloudSuite Fashion, M3, and LN, among others. The ION API Gateway acts as a centralized OAuth 2.0 authorization server, while Infor Federated Services (IFS) handles identity federation and claims management. This card does NOT cover on-premises Infor OS deployments (which use IFS with ADFS/claims-based auth) or IFS Cloud from IFS AB (a completely different vendor and product).

API Surfaces & Capabilities

The ION API Gateway is the single entry point for all API traffic to Infor CloudSuite applications. All external API calls must be authenticated through the gateway using OAuth 2.0 Bearer tokens.

Rate Limits & Quotas

Per-Request Limits

Rolling / Daily Limits

Authentication

All ION API Gateway authentication flows are mediated by Infor Federated Services (IFS), which acts as the claims provider and identity federation hub. The IFS authorization server issues OAuth 2.0 tokens after authenticating the user or service account.

Authentication Gotchas

• Refresh tokens are OFF by default: Unlike most OAuth 2.0 implementations, Infor's ION API Gateway does NOT issue refresh tokens unless the "Issue Refresh Token" toggle is explicitly enabled per authorized application. [src5]
• Four credentials for backend services: The Resource Owner grant requires ClientID, ClientSecret, Service Account AccessKey (saak), and Service Account SecretKey (sask). This is unique to Infor. [src2, src3]
• Scope mismatch returns 403, not 401: If scopes in your SAML assertion or authorized app configuration do not match the scopes required by the target API, the ION API Gateway returns HTTP 403, not 401. [src2]
• Refresh token rotation is enabled by default in 2025.x+: Refresh tokens rotate every ~8 hours. If your application caches the original refresh token, token exchange fails silently. [src5]
• 30-day idle expiry: Even with infinite grant lifetime configured, a refresh token unused for 30 consecutive days is automatically invalidated. [src5]

Constraints

• Backend service accounts are user-bound -- each service account is associated with a specific IFS user, and API calls execute under that user's permissions and security roles. [src6]
• ION API Gateway is the only external entry point -- you cannot bypass the gateway to call Infor CloudSuite APIs directly. [src2]
• The .ionapi file is tenant-specific -- credentials downloaded for one tenant do not work in another. [src6]
• Scope configuration is required per authorized app -- scopes are not inherited or global. [src2]
• Token endpoint URLs vary by tenant -- the authorization and token endpoints are tenant-specific URLs embedded in the .ionapi file. Do not hardcode them. [src2, src3]
• On-premises IFS uses different auth -- on-premises Infor OS uses IFS with ADFS (claims-based), not OAuth 2.0 via the ION API Gateway. [src1]

Integration Pattern Decision Tree

START -- Authenticate with Infor CloudSuite via ION API Gateway
|-- What type of application?
|   |-- Backend service / daemon / ETL (no user present)
|   |   |-- Have .ionapi credentials file?
|   |   |   |-- YES --> Resource Owner Grant using saak + sask + ci + cs
|   |   |   |-- NO --> Register Backend Service app in ION API Gateway,
|   |   |       enable "Create Service Account", download .ionapi
|   |   |-- Need long-running session (>2h)?
|   |       |-- YES --> Enable "Issue Refresh Token" on the authorized app
|   |       |-- NO --> Request new access token per session (simple)
|   |-- Web application (user login required)
|   |   |-- Server-side web app
|   |   |   --> Authorization Code Grant (register as Web Application type)
|   |   |-- SPA / client-side only
|   |       --> Implicit Grant (consider Auth Code + PKCE if supported)
|   |-- App embedded in Infor Ming.le portal
|   |   --> SAML Bearer Grant (reuse SSO token from Ming.le)
|   |-- Infor Data Lake / ETL extraction
|       --> Backend Service (Resource Owner) with .ionapi file
|-- Which credential file format?
|   |-- .ionapi file (JSON with ti, cn, ci, cs, iu, pu, oa, ot, saak, sask)
|   |   --> Parse file, extract endpoints and credentials
|   |-- Manual ClientID/Secret (registered but no .ionapi)
|       --> Obtain token endpoint from Infor OS admin portal
|-- Token refresh strategy?
    |-- Short jobs (<2h) --> No refresh needed, single token per job
    |-- Long jobs (>2h) --> Enable refresh tokens, handle rotation
    |-- Idle >30 days --> Must re-authenticate; refresh token auto-invalidated

Quick Reference

Step-by-Step Integration Guide

1. Register an authorized application in ION API Gateway

Navigate to Infor OS > API Gateway > Authorized Apps. Create a new authorized application. Select "Backend Service" for server-to-server integrations. Enable "Create Service Account" and associate it with an IFS user. Download the .ionapi credentials file. [src2, src6]

Infor OS steps:
1. Log in to Infor OS (your CloudSuite portal)
2. Navigate to Burger menu > API Gateway > Authorized Apps
3. Click "+" to create new authorized app
4. For Backend Service:
   a. Select type: "Backend Service"
   b. Enable "Create Service Account"
   c. Select user to associate with service account
   d. Optionally add scopes
5. Save and download the .ionapi credentials file
6. Store the .ionapi file securely

Verify: Open the .ionapi file and confirm it contains ci, cs, pu, oa, ot fields. For backend services, also confirm saak and sask are present.

2. Parse the .ionapi credentials file

The .ionapi file is a JSON file containing all endpoints and credentials needed for authentication. [src3]

import json

def parse_ionapi(filepath):
    with open(filepath, 'r') as f:
        creds = json.load(f)
    return {
        'client_id': creds['ci'],
        'client_secret': creds['cs'],
        'token_endpoint': f"{creds['pu']}/{creds['ot']}",
        'ionapi_url': creds.get('iu', ''),
        'saak': creds.get('saak', ''),
        'sask': creds.get('sask', ''),
    }

creds = parse_ionapi('/path/to/credentials.ionapi')

Verify: The parsed token_endpoint URL should be a valid HTTPS URL.

3. Acquire access token (Resource Owner grant)

For server-to-server integrations, POST to the token endpoint with all four credentials. [src2, src3]

import requests

response = requests.post(creds['token_endpoint'], data={
    'grant_type': 'password',
    'username': creds['saak'],
    'password': creds['sask'],
    'client_id': creds['client_id'],
    'client_secret': creds['client_secret'],
})
token_data = response.json()
print(f"Token: {token_data['access_token'][:20]}...")

Verify: Response contains access_token and token_type of Bearer. expires_in should be approximately 7200.

4. Call an ION API with the Bearer token

Include the access token as a Bearer token in the Authorization header. [src2]

headers = {
    'Authorization': f"Bearer {token_data['access_token']}",
    'Accept': 'application/json',
}
response = requests.get(
    f"{creds['ionapi_url']}/ifsservice/usermgt/v2/users/me",
    headers=headers
)
print(response.json())

Verify: GET /ifsservice/usermgt/v2/users/me returns JSON with user details. HTTP 200 confirms auth is working.

5. Handle token refresh

If refresh tokens are enabled, exchange the refresh token for a new access token before expiry. Always store the latest rotated refresh token. [src5]

new_tokens = requests.post(creds['token_endpoint'], data={
    'grant_type': 'refresh_token',
    'refresh_token': token_data['refresh_token'],
    'client_id': creds['client_id'],
    'client_secret': creds['client_secret'],
}).json()
# CRITICAL: Store the NEW refresh_token -- it rotates every ~8h
current_refresh = new_tokens.get('refresh_token', token_data['refresh_token'])

Verify: New access_token returned with fresh expires_in.

6. Revoke tokens on completion

Revoke refresh tokens at the end of integration sessions to prevent orphan grants. [src3]

requests.post(
    f"{creds['portal_url']}/revoke_token.oauth2",
    data={'token': refresh_token, 'token_type_hint': 'refresh_token'},
    auth=(creds['client_id'], creds['client_secret'])
)

Verify: HTTP 200. Subsequent API calls with revoked token return 401.

Code Examples

Python: Complete Backend Service Authentication

# Input:  .ionapi credentials file path
# Output: Authenticated API call to Infor ION API Gateway

import json, requests, time

class InforAuthClient:
    def __init__(self, ionapi_path):
        with open(ionapi_path, 'r') as f:
            creds = json.load(f)
        self.client_id = creds['ci']
        self.client_secret = creds['cs']
        self.token_url = f"{creds['pu']}/{creds['ot']}"
        self.ionapi_url = creds.get('iu', '')
        self.saak = creds.get('saak', '')
        self.sask = creds.get('sask', '')
        self._token = None
        self._token_expiry = 0

    def get_token(self):
        if self._token and time.time() < self._token_expiry - 300:
            return self._token
        resp = requests.post(self.token_url, data={
            'grant_type': 'password',
            'username': self.saak, 'password': self.sask,
            'client_id': self.client_id, 'client_secret': self.client_secret,
        })
        resp.raise_for_status()
        data = resp.json()
        self._token = data['access_token']
        self._token_expiry = time.time() + data.get('expires_in', 7200)
        return self._token

    def call_api(self, endpoint, method='GET', payload=None):
        headers = {'Authorization': f'Bearer {self.get_token()}', 'Accept': 'application/json'}
        resp = requests.request(method, f'{self.ionapi_url}{endpoint}', headers=headers, json=payload)
        resp.raise_for_status()
        return resp.json()

client = InforAuthClient('/path/to/credentials.ionapi')
user = client.call_api('/ifsservice/usermgt/v2/users/me')
print(f"Connected as: {user}")

JavaScript/Node.js: Backend Service Authentication

// Input:  Path to .ionapi credentials file
// Output: Authenticated API call to ION API Gateway
// npm install axios
const axios = require('axios');
const fs = require('fs');

class InforAuthClient {
  constructor(ionapiPath) {
    const creds = JSON.parse(fs.readFileSync(ionapiPath, 'utf8'));
    this.clientId = creds.ci;
    this.clientSecret = creds.cs;
    this.tokenUrl = `${creds.pu}/${creds.ot}`;
    this.ionapiUrl = creds.iu || '';
    this.saak = creds.saak || '';
    this.sask = creds.sask || '';
    this._token = null;
    this._tokenExpiry = 0;
  }

  async getToken() {
    if (this._token && Date.now() < this._tokenExpiry - 300000) return this._token;
    const params = new URLSearchParams({
      grant_type: 'password', username: this.saak, password: this.sask,
      client_id: this.clientId, client_secret: this.clientSecret,
    });
    const resp = await axios.post(this.tokenUrl, params.toString(),
      { headers: { 'Content-Type': 'application/x-www-form-urlencoded' } });
    this._token = resp.data.access_token;
    this._tokenExpiry = Date.now() + (resp.data.expires_in || 7200) * 1000;
    return this._token;
  }

  async callApi(endpoint, method = 'GET', data = null) {
    const token = await this.getToken();
    const resp = await axios({ method, url: `${this.ionapiUrl}${endpoint}`,
      headers: { Authorization: `Bearer ${token}`, Accept: 'application/json' }, data });
    return resp.data;
  }
}

(async () => {
  const client = new InforAuthClient('/path/to/credentials.ionapi');
  const user = await client.callApi('/ifsservice/usermgt/v2/users/me');
  console.log('Connected as:', user);
})();

cURL: Quick token acquisition and API test

# Input:  .ionapi file with ci, cs, saak, sask, pu, ot, iu
# Output: Access token + IFS user info

IONAPI_FILE="/path/to/credentials.ionapi"
CI=$(jq -r '.ci' "$IONAPI_FILE")
CS=$(jq -r '.cs' "$IONAPI_FILE")
SAAK=$(jq -r '.saak' "$IONAPI_FILE")
SASK=$(jq -r '.sask' "$IONAPI_FILE")
PU=$(jq -r '.pu' "$IONAPI_FILE")
OT=$(jq -r '.ot' "$IONAPI_FILE")
IU=$(jq -r '.iu' "$IONAPI_FILE")

# Acquire token
TOKEN=$(curl -s -X POST "${PU}/${OT}" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=password&username=${SAAK}&password=${SASK}&client_id=${CI}&client_secret=${CS}" \
  | jq -r '.access_token')

# Verify
curl -s "${IU}/ifsservice/usermgt/v2/users/me" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/json" | jq .

Data Mapping

.ionapi File Field Reference

Data Type Gotchas

• Token endpoint URLs are tenant-specific: The pu, oa, and ot values vary per tenant. Always construct endpoints from the .ionapi file. [src2, src3]
• saak and sask are NOT the same as ClientID/ClientSecret: Confusing the two pairs results in authentication failure. [src3]
• The iu (ION API URL) may differ from pu (Portal URL): Do not use pu to construct API call URLs. [src3]

Error Handling & Failure Points

Common Error Codes

Failure Points in Production

• Refresh token rotation breaks long-running ETL jobs: Tokens rotate every ~8h. Caching initial refresh token causes invalid_grant. Fix: Always store and use the LATEST refresh_token from each token response. [src5]
• 30-day idle invalidation kills seasonal integrations: Monthly/quarterly integrations lose refresh tokens. Fix: Implement a keep-alive job using the refresh token at least once every 25 days. [src5]
• .ionapi file committed to version control: Contains four plaintext credentials. Fix: Add *.ionapi to .gitignore. Store in secrets manager. Load at runtime from env vars. [src3]
• Service account user disabled in IFS: Tokens can still be issued but all API calls return 403. Fix: Monitor IFS user account status. Use dedicated integration user excluded from bulk management. [src6]
• Scope changes require new .ionapi file: Adding scopes after generating credentials may not take effect. Fix: Re-download .ionapi file after scope changes. [src2]

Anti-Patterns

Wrong: Hardcoding token endpoint URLs

# BAD -- endpoint URL hardcoded, breaks when switching tenants
TOKEN_URL = "https://mingle-ionapi.inforcloudsuite.com/TENANT_ID/as/token.oauth2"
response = requests.post(TOKEN_URL, data=payload)

Correct: Read endpoints from .ionapi file

# GOOD -- endpoints parsed from .ionapi file, portable across environments
with open('credentials.ionapi', 'r') as f:
    creds = json.load(f)
token_url = f"{creds['pu']}/{creds['ot']}"
response = requests.post(token_url, data=payload)

Wrong: Ignoring refresh token rotation

# BAD -- caches initial refresh_token, ignores rotated token
initial_refresh = token_data['refresh_token']
for batch in batches:
    new_tokens = refresh(initial_refresh)  # Fails after ~8h
    process(batch, new_tokens['access_token'])

Correct: Always store the latest rotated refresh token

# GOOD -- updates refresh_token from every response
current_refresh = token_data['refresh_token']
for batch in batches:
    new_tokens = refresh(current_refresh)
    current_refresh = new_tokens.get('refresh_token', current_refresh)
    save_to_disk(current_refresh)
    process(batch, new_tokens['access_token'])

Wrong: Using same .ionapi file across tenants

# BAD -- one .ionapi file reused for dev, test, and prod
client = InforAuthClient('shared-credentials.ionapi')

Correct: Separate .ionapi files per environment

# GOOD -- environment-specific credentials
import os
env = os.environ.get('INFOR_ENV', 'dev')
client = InforAuthClient(f'/secrets/infor-{env}.ionapi')

Common Pitfalls

• Confusing Infor IFS with IFS Cloud: "IFS" stands for "Infor Federated Services" in the Infor ecosystem, but "IFS Cloud" is a completely different ERP from IFS AB (a Swedish company). Fix: Always clarify which "IFS" the user means before recommending an auth flow. [src1]
• Not enabling refresh tokens before go-live: Refresh tokens are disabled by default. Short test sessions work fine, but production batch jobs >2h fail. Fix: Enable "Issue Refresh Token" on every authorized app used for production integrations exceeding 2 hours. [src5]
• Using pu instead of iu for API calls: The .ionapi file has two base URLs: pu (portal/auth) and iu (API). Using portal URL for API calls returns 404. Fix: Use pu for auth endpoints, iu for all business API calls. [src3]
• Forgetting to associate scopes: An app with no scopes can get tokens but cannot access scope-restricted APIs. Error is 403, not a clear "missing scope" message. Fix: Configure required scopes during authorized app registration. [src2]
• Not revoking tokens on job completion: Orphan grants accumulate. Fix: Always revoke refresh tokens at end of sessions. Implement shutdown hooks. [src3]
• Testing with admin user, deploying with restricted service account: API calls work in dev but return 403 in prod. Fix: Test with the actual service account user from day one. [src6]

Diagnostic Commands

# Parse .ionapi file and display endpoints (mask secrets)
IONAPI_FILE="/path/to/credentials.ionapi"
jq '{tenant: .ti, name: .cn, portal_url: .pu, ionapi_url: .iu, has_saak: (.saak != null)}' "$IONAPI_FILE"

# Acquire token and display metadata
CI=$(jq -r '.ci' "$IONAPI_FILE"); CS=$(jq -r '.cs' "$IONAPI_FILE")
SAAK=$(jq -r '.saak' "$IONAPI_FILE"); SASK=$(jq -r '.sask' "$IONAPI_FILE")
PU=$(jq -r '.pu' "$IONAPI_FILE"); OT=$(jq -r '.ot' "$IONAPI_FILE")

TOKEN_RESPONSE=$(curl -s -X POST "${PU}/${OT}" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=password&username=${SAAK}&password=${SASK}&client_id=${CI}&client_secret=${CS}")

echo "$TOKEN_RESPONSE" | jq '{token_type, expires_in, scope, has_refresh: (.refresh_token != null)}'

# Test API access
IU=$(jq -r '.iu' "$IONAPI_FILE")
TOKEN=$(echo "$TOKEN_RESPONSE" | jq -r '.access_token')
curl -s "${IU}/ifsservice/usermgt/v2/users/me" -H "Authorization: Bearer $TOKEN" -H "Accept: application/json" | jq .

# Check if specific API scope is accessible
curl -s -o /dev/null -w "%{http_code}" "${IU}/YOUR_API_ENDPOINT" -H "Authorization: Bearer $TOKEN"
# 200 = OK, 403 = scope missing

Version History & Compatibility

When to Use / When Not to Use

Important Caveats

• Infor Federated Services (IFS) is NOT the same product as IFS Cloud from IFS AB. They share the "IFS" abbreviation but are completely different vendors, products, and authentication stacks.
• The ION API Gateway rate limits (quota, throttling, spike arrest) are configured per-endpoint by Infor administrators and vary across tenants. Default values in documentation are examples, not universal defaults.
• Service account users operate under the associated user's full security context. If that user gains or loses roles, integration permissions change without OAuth-level notification.
• The .ionapi credential file format is Infor-proprietary. When integrating with iPaaS platforms, you must extract individual fields and configure them separately in the iPaaS connector.
• Access token lifetime (~2h) and refresh token rotation (~8h) are approximate and may be adjusted by tenant administrators. Always check expires_in from the token response.