Application settings

The Settings tab is where you change how an application presents itself to users and how the OAuth protocol handles its tokens. Most integration problems — wrong redirect, unexpected CORS error, token expiring too soon — trace back to a field on this page.

Screenshot pending /screenshots/admin.applications.settings/tab.png

General

The General section covers the fields that show up anywhere your application's identity is displayed.

Name is required and appears on the OAuth consent screen that users see when they authorise the application. Choose something your users will recognise — "Cymmetri HR Portal" rather than "app-prod-1". Keep it short enough to render cleanly on a phone screen.

Description is an internal note. It is never shown to end users. Use it for context that helps your team — which team owns this, what environment it is, a link to the relevant Jira project.

Logo URL appears on the consent screen and on any application-selection dashboard. Provide a publicly accessible HTTPS URL pointing to a square image at least 200 px on a side. If the URL is unreachable or returns a non-image response, IntelliAuth falls back to a generic application icon silently — check that the URL loads in an incognito browser tab before saving.

Redirect URIs

Not applicable to M2M applications

Machine-to-machine applications use the client credentials grant, which has no browser redirect step. This section does not appear for M2M applications.

Callback URLs

A Callback URL is where IntelliAuth sends the user — along with the authorization code — at the end of a successful login. The OAuth protocol requires an exact match: the redirect_uri your application sends in the authorization request must be in this list character-for-character.

Common causes of redirect mismatch errors:

A trailing slash on one side but not the other (/callback vs /callback/).
http in development but https in the saved list, or the reverse.
A port number included in the request but absent from the saved URL.
A staging subdomain that was never added.

The fix in every case is to add the exact URL as the application actually sends it. Add all environments — localhost for development, your staging subdomain, and your production URL. Having all three in the list does not weaken security; IntelliAuth only redirects to the URL the application requests, and only if it matches.

Logout URLs

A Logout URL is where IntelliAuth sends the user after a sign-out flow completes. The same exact-match rule applies. If the application's sign-out request specifies a post_logout_redirect_uri, that URI must be in this list.

Logout URLs are separate from Callback URLs because different parts of your application may handle these redirects. A sign-in lands at /callback; a sign-out lands at / or /signed-out. Keep them separate and explicit.

Web Origins (SPA only)

SPA applications only

The Web Origins field appears only for Single-Page Application types. Server-side and native applications do not make cross-origin XHR requests and do not need this field.

CORS (Cross-Origin Resource Sharing) is the browser mechanism that blocks a page on app.cymmetri.io from making requests to auth.cymmetri.io unless the server explicitly permits it. IntelliAuth's token endpoint uses CORS; if your SPA's origin is not in this list, the browser will refuse the token exchange before it reaches the server.

Add the origin — scheme plus host plus port, no path — for every environment where the SPA runs. http://localhost:3000 for development, https://app.cymmetri.io for production. A mismatch here produces a CORS preflight failure in the browser console, not a redirect error, which makes it a different failure mode from a callback URL mismatch.

Token Lifetimes

The Token Lifetimes section lets you override the tenant-wide defaults for this specific application. Leave a field empty to inherit the tenant default.

Values use a duration string format: 1h for one hour, 30m for thirty minutes, 720h for thirty days. Minutes (m) and hours (h) are supported.

The three knobs:

Access Token — how long an access token is valid before the client must exchange a refresh token for a new one. Available for all application types including M2M.
ID Token — how long the identity token issued at login is considered valid. Not applicable to M2M applications.
Refresh Token — how long the client can use a refresh token to obtain new access tokens without prompting the user to sign in again. Not applicable to M2M applications.

Trade-offs

Shorter access token lifetimes reduce the blast radius of a leaked token — an attacker has less time to use it — but increase the frequency of refresh-token exchanges and add latency to long-running sessions. Longer refresh token lifetimes reduce re-authentication friction for users, but a leaked refresh token lets an attacker mint access tokens until the refresh token expires or is revoked. A common starting point: access tokens at 15m, refresh tokens at 720h (thirty days), with explicit revocation on sign-out.

Application type notes

Settings that appear depend on the application type:

M2M — no Redirect URIs section (no browser involved), no ID Token or Refresh Token fields (client credentials grant issues access tokens only), Access Token lifetime is the only token knob.
SPA — has Callback URLs, Logout URLs, and Web Origins. Web Origins does not appear for any other type.
Web and Native — have Callback URLs and Logout URLs; no Web Origins field.
SAML — displays a separate SAML-specific panel (Entity ID, ACS URL, certificate, attribute statements) that is not part of this tab. The fields documented above still apply to the OIDC side of a SAML application where relevant.