Manage applications

Register and manage applications in Scalekit. Each application gets its own OAuth client and configuration while sharing the same underlying user session across your web, mobile, and desktop apps.

1. Navigate to Applications

   1. Sign in to https://app.scalekit.com
   2. From the left sidebar, go to Developers > Applications

   You will see a list of applications already created for the selected environment.

   Scalekit creates a default web application

   Scalekit creates a default web application for every environment at creation time to help developers get started quickly. This app is environment-scoped and cannot be deleted.

2. Create a new application

   Click Create Application to add a new app. You’ll be asked to provide:

   • Application name — A human-readable name for identifying the app
   • Application type — Determines how authentication and credentials work

   Available application types:

   • Web Application — Server-side applications that can securely store secrets
   • Single Page Application (SPA) — Browser-based applications; public clients with PKCE enforced
   • Native Application — Desktop or mobile apps; public clients with PKCE enforced

   

   Once created, Scalekit generates a Client ID. Only Web Applications can generate Client Secrets.

3. Application configuration

   Application details

   Open an application to view and edit its configuration.

   • Allow Scalekit Management API access — Enables this application’s credentials to call Scalekit Management APIs. Applicable only to Web Applications.
   • Enforce PKCE — Requires PKCE for authorization requests. Always enabled and not editable for SPA and Native applications.
   • Access token expiry time — Overrides the environment default access token lifetime for this application.

   Access token expiry must be shorter than idle session timeout

   If tokens outlive the session, users may encounter inconsistent logout behavior across apps. When the session expires but the access token is still valid, subsequent token refresh attempts will fail because the underlying session no longer exists.

   

   Client credentials

   Each application has a unique Client ID. When you generate a new client secret, Scalekit shows it only once. Copy and store it securely.

   Treat client secrets like passwords

   Anyone with access to your client secret can authenticate as your application and obtain tokens for any user. Never commit secrets to version control, expose them in client-side code, or share them in plain text. Use environment variables or a secrets manager.

   • Web Applications
     • Can generate a Client Secret
     • A maximum of two active secrets is allowed at a time
     • Generating a new secret always creates a new value, enabling safe rotation

   

   • SPA and Native Applications
     • Do not have client secrets
     • Authenticate using Authorization Code with PKCE only

   

4. Configure redirect URLs

   Open the Redirects tab for an application to manage redirect endpoints. These URLs act as an allowlist and control where Scalekit can redirect users during authentication flows.

   Redirect URL types

   • Post login URLs — Allowed values for redirect_uri used with /oauth/authorize
   • Initiate login URL — Where Scalekit redirects users when authentication starts outside your app
   • Post logout URLs — Where users are redirected after a successful logout
   • Back-channel logout URL — A secure endpoint that Scalekit calls to notify your application that a user session has been revoked

   

   Back-channel logout is only available for Web Applications

   Back-channel logout requires a backend endpoint to receive notifications from Scalekit. SPA and Native applications cannot receive back-channel logout notifications because they don’t have a persistent server.

   For definitions, validation rules, custom URI schemes, and environment-specific behavior, see Redirect URL configuration.

5. Delete an application

   Delete applications from the bottom of the configuration page.

   

   Deleting an application is permanent

   This action is permanent and irreversible. Existing refresh tokens associated with the application will no longer be valid, and users will need to re-authenticate. Ensure you have communicated this change to affected users before deleting.