Summary
When configuring OAuth authentication for exacqVision using Okta or Microsoft Entra ID, Enterprise Manager and the desktop client may authenticate successfully while exacqVision Mobile fails with a 400 error. Typical error text seen in the mobile application includes:
Identity Provider: Unknown
invalid_request
This behavior occurs even when the OAuth configuration appears to match current Exacq documentation. The root cause is additional identity‑provider configuration that is required specifically for native mobile OAuth flows but is not fully outlined in existing documentation.
This KB documents the missing configuration items, why they are required, and when they are most likely to apply.
Why This Happens
exacqVision uses three different OAuth client models:
-Enterprise Manager uses a confidential web application.
-exacqVision Client (desktop) uses a native application with a loopback redirect.
-exacqVision Mobile uses a native application with a custom URI scheme.
Desktop OAuth commonly works because loopback redirects are treated leniently by most identity providers. Mobile OAuth uses a custom URI scheme and a non‑browser initiation flow, which triggers additional identity‑provider validation.
These additional validations are often enforced when:
-Enterprise Manager is accessed through a reverse proxy or load balancer
-HTTPS is terminated externally
-Wildcard TLS certificates are used
-Remote Access Code is used in exacqVision Mobile
Symptoms
-Enterprise Manager OAuth login works
-exacqVision Client OAuth login works
-exacqVision Mobile returns HTTP 400
-Mobile error text includes “Identity Provider: Unknown” or “invalid_request”
-No OAuth errors appear in Enterprise Manager logs
-Token preview or test tokens in Okta / Entra ID succeed
These symptoms indicate the failure is occurring at the identity provider’s authorization endpoint before the request reaches Enterprise Manager.
Okta Configuration Requirements when this scenario occurs:
- Mobile Redirect URI Must Be Under Sign‑In Redirect URIs
Common mistake:
exacqvisionmobile://callback/ is placed only under Sign‑out redirect URIs
Required configuration for the Native Okta application:
Sign‑in redirect URIs must include:
http://localhost:55911/callback
exacqvisionmobile://callback/
Reason:
Okta validates redirect URIs during sign‑in only. Sign‑out redirect URIs are ignored during the authorization flow. If the mobile URI is missing from sign‑in, Okta rejects the request with invalid_request.
- Initiate Login URI Must Be Set for the Native App
Native applications do not automatically allow login initiation.
Required configuration (Native App, General → Login section):
Initiate login URI:
https://
Example:
https://em.example.com
Reason:
exacqVision Mobile initiates OAuth outside of a traditional browser session. Okta requires an explicit login initiation URL for native mobile flows. Desktop client loopback redirects do not require this setting, which is why desktop works without it.
- Trusted Origin Required for Mobile OAuth
Required configuration in Okta:
Security → API → Trusted Origins
Add a Trusted Origin for the public Enterprise Manager URL:
Origin URL: https://
Types enabled:
CORS
Redirect
Reason:
Mobile OAuth requests originate from a non‑browser context. Okta enforces origin validation for these flows, especially behind reverse proxies. Without a Trusted Origin, Okta rejects the authorize request before Enterprise Manager receives it.
- Native App Grant Type Confirmation
The following grant types must be configured on the Native App:
-Authorization Code
-Refresh Token
The following must not be enabled on the Native App:
-Client Credentials
Notes:
-PKCE will be enforced automatically (often shown as enabled and greyed out)
-These settings do not conflict with exacqVision Client
-Client Credentials is intended only for the Enterprise Manager Web App
Why This Commonly Appears Behind Reverse Proxies
When Enterprise Manager is accessed through NGINX, load balancers, or SSL termination:
-The IdP sees requests originating from the public hostname
-Native mobile flows are validated more strictly
-Identity providers require explicit origin and login permissions that are not required for browser or desktop flows
This explains why:
-Enterprise Manager login works
-Desktop client works
-Mobile fails until these IdP settings are added
Microsoft Entra ID (Azure AD) Notes
These same concepts apply to Entra ID, with different terminology:
-Native App corresponds to a Public Client
-Redirect URIs must be registered under Mobile and desktop applications
-exacqvisionmobile://callback/ must be explicitly added
-The Application/Home page URI should match the public Enterprise Manager URL
-Reverse proxy deployments increase the likelihood that missing App URI or redirect configuration will cause mobile OAuth failure
Missing these settings in Entra ID can result in the same invalid_request behavior.
Resolution Checklist
For mobile OAuth with Okta or Entra ID, confirm all of the following:
-Native application is used for desktop and mobile
-exacqvisionmobile://callback/ exists under Sign‑in redirect URIs
-Initiate login URI is set to the public Enterprise Manager URL
-Trusted Origin exists for the EM URL with CORS and Redirect enabled
-Authorization Code and Refresh Token grants enabled
-Client Credentials disabled on the Native App
-Enterprise Manager URL uses HTTPS and matches IdP configuration
Conclusion
exacqVision Mobile OAuth requires additional identity‑provider configuration beyond Enterprise Manager and desktop client OAuth. These requirements are enforced by Okta and Entra ID for native mobile applications, particularly when custom URI schemes and reverse proxies are involved.
If a customer reports that EM and desktop OAuth work but mobile returns 400 invalid_request errors, review the items in this KB before escalating to engineering.