Authenticate users and service clients
Choose a grant, send the correct token parameters and manage bearer-token expiry.
Most protected IFBI API operations use a bearer access token obtained from POST /api/token. Choose the grant that matches the installation’s identity configuration and the endpoints your integration needs.
Send the token request to your installation’s API URL, normally on port 50255. The web application normally uses HTTPS on port 443 and is a separate IIS application. See Connect to your IntelliFront installation to confirm the correct API address.
Choose the authentication flow
| Grant | Main inputs | When it applies |
|---|---|---|
password | username and password | Authenticate an IFBI user; use domain_user=true for domain login where configured. |
client_credentials | Registered client_id and client_secret | Authenticate an authorised service client with the SERVICE claim. |
adsso | authdata in the query string | Use the configured Active Directory SSO flow. |
customauth | session_id in the query string | Use the configured custom-authentication flow; the remote IP address also participates. |
msgraphsso | access_token in the token parameters | Use the configured Microsoft Graph SSO flow. |
Use the token reference for the complete contract. The token request is form-encoded. Service-client credentials can be sent as form fields or HTTP Basic credentials. User authentication with a required one-time passcode sends X-OTP as a form field.
Match the identity to the endpoint
A background integration may use client credentials, but that does not make every user-oriented endpoint suitable for it. Canvas and preference operations can require a current user ID. Check the operation and use an appropriately authorised user identity when that context is needed.
Administrators can use Register API client as part of service-client setup. Registration and the SERVICE claim are separate requirements to verify with the installation administrator. Store the returned credential material securely.
Reuse tokens and handle expiry
The token response contains access_token, token_type and expires_in. It is a plain object, not a Data wrapper. Send the access token in the Authorization header on subsequent protected requests.
Use expires_in to plan renewal. Token lifetime depends on deployment configuration. Obtain a new token through the chosen grant when needed; do not assume a refresh-token grant is available. Protect token acquisition against concurrent renewal attempts in a busy application.
Use the standard /api/token path unless your installation specifically requires the documented alternate middleware path. The alternate path has exact-path constraints; it is not a general alias for all API routes.
See the authentication recipe in Recipes, then handle response shapes and errors.
Updated 16 minutes ago