Managing Applications

Applications in Auris represent the OAuth 2.0 client registrations for your web apps, mobile apps, APIs, and machine-to-machine services. Every client that connects to Auris to authenticate users or obtain tokens must first be registered as an application.

The Applications section of the Console is where you create and manage these registrations, configure the OAuth settings each client needs, and control what data appears in the tokens your applications receive.

Application Types

Auris supports four application types. Choose the type that best matches your client’s architecture:

Note: For WEB and MOBILE applications, do not embed the client secret in your frontend code. PKCE (Proof Key for Code Exchange) provides equivalent security without requiring a secret on the client side.

Creating an Application

Application Detail Page

Once an application is created, clicking its name opens the detail page. The detail page is organized into tabs:

Credentials Tab

The Credentials tab shows the OAuth identifiers for this application.

Client ID

The client ID is a unique identifier assigned by Auris at creation time. It is safe to expose in frontend code. Use this value as the clientId in your SDK configuration.

your-client-id-here

Client Secret (M2M and API applications only)

The client secret is shown in full only once — immediately after creation. After you leave the Credentials tab, the Console displays only the last four characters.

To view or rotate the secret:

1. Click Show Secret to reveal the last-four-character preview
2. Click Rotate Secret to generate a new secret

Note: When you rotate a client secret, the old secret remains valid for a grace period of 24 hours. This allows you to update your server-side configuration without causing an immediate authentication failure. After the grace period, the old secret is permanently invalidated.

Store client secrets securely. Treat them as passwords — never commit them to source control or expose them in logs.

URIs Tab

The URIs tab configures which URLs Auris will interact with for this application.

Redirect URIs (Allowed Callback URLs)

These are the URLs Auris is permitted to redirect to after a successful authorization code exchange. The redirect_uri provided at runtime must exactly match one of the registered values — partial matches, wildcards, and trailing slash mismatches are all rejected.

Add one URI per line. Typical values:

https://app.yourdomain.com/auth/callback
http://localhost:3000/auth/callback

Allowed Origins (CORS)

Origins from which the browser is allowed to make direct requests to the Auris API. Used for cross-origin token refresh requests from SPAs. Enter origins without a trailing path:

https://app.yourdomain.com
http://localhost:3000

Logout URLs

URLs Auris is permitted to redirect to after a logout request (/logout endpoint). Add the post-logout landing page for your application:

https://app.yourdomain.com
http://localhost:3000

Settings Tab

The Settings tab controls token lifetimes and grant type permissions.

Refresh Token Rotation

When enabled (default), each use of a refresh token issues a new refresh token and invalidates the one that was just used. This limits the window of exposure if a refresh token is stolen, because the legitimate client will detect that its token was already used and can revoke the session.

Custom Claims Tab

Custom claims allow you to embed additional data into the JWT access tokens issued for this application. Claims are evaluated at token issuance time and vary per user.

Claim Types

Adding a Claim

1. Click Add Claim
2. Enter the Claim Key — this is the property name that will appear in the JWT payload (for example, department, plan, org_id)
3. Select the Value Type from the dropdown
4. Configure the value source based on the type
5. Toggle Active on to include this claim in issued tokens
6. Click Save

Preview

Use the Preview button to test claim resolution. Enter a user ID and click Preview to see what the JWT payload would look like for that user with all configured claims applied.

For implementation details on reading custom claims in your SDK, see Custom Claims.

M2M Scopes Tab

This tab is only visible for applications of type M2M. It controls which scopes a machine-to-machine client is permitted to request when using the client_credentials grant type.

Scope Format

Scopes follow the action:resource format, matching the same permission format used throughout Auris:

read:users
write:invoices
admin:reports

Configuring Scopes

1. Click Add Scope
2. Enter the scope string (for example, read:orders)
3. Optionally add a description for the scope
4. Click Save

When the M2M client requests a token, it may only request scopes that are listed here. Requesting an unlisted scope results in an error.

Verifying Scopes on Your API

Your API server should validate that the incoming token contains the required scope before serving a request:

// Node.js example — verify M2M token scope
import { createLocalJWKSet, jwtVerify } from 'jose'
 
export async function verifyM2MToken(bearerToken, requiredScope) {
  const JWKS = createLocalJWKSet(await fetchJwks())
  const { payload } = await jwtVerify(bearerToken, JWKS)
 
  if (payload.type !== 'm2m') {
    throw new Error('Not an M2M token')
  }
 
  const scopes = payload.scope?.split(' ') ?? []
  if (!scopes.includes(requiredScope)) {
    throw new Error(`Missing required scope: ${requiredScope}`)
  }
 
  return payload
}

For full M2M implementation details, see M2M Client Credentials.

Deleting an Application

To delete an application:

1. Open the application detail page
2. Scroll to the bottom of the Settings tab
3. Click Delete Application
4. Confirm deletion in the dialog

Note: Deleting an application is permanent. Any tokens issued for this application will become unverifiable after deletion, since the client ID will no longer exist. Ensure all running services using this application’s credentials have been updated before deleting.

Related Guides

• Hosted Login (Authorization Code + PKCE) — Implement OAuth 2.0 PKCE in your frontend
• M2M Client Credentials — Server-to-server authentication with client credentials
• Custom Claims — Embed user and role data in JWT tokens
• Token Verification — Validate Auris JWTs on your API server