Applications

A default application is automatically generated for each environment. If your product only has one client, no action is needed. You can see and set your application’s API keys, Redirects and Sessions configuration in the Applications section of the WorkOS Dashboard.

Multiple Applications lets developers define each client as its own application object within an environment in the WorkOS Dashboard. Each application gets its own client ID, session configuration, redirect URIs, and credentials, while sharing the same underlying user base. Users and organizations are shared across applications with a unified login experience, without duplicate accounts or fragmented identity data.

One product spanning multiple client surfaces

Web app + mobile app + desktop client: model all three surfaces explicitly, each with platform-appropriate behavior.

Multiple products with a shared user base

App A + App B + App C: define each as its own application with appropriate session lifetimes and redirect URIs.

Multiple Applications is not the right fit for every scenario.

If you need entirely separate user bases, use separate environments instead. Each environment maintains its own isolated set of users and organizations. For a fully separate setup – with its own branding, configuration, and staging and production environments – use a separate project.

Environments with more than one application can give each application its own branding for the hosted AuthKit UI while sharing the same user base. Each application uses the environment’s branding by default; you can customize it from the application’s details page or the Branding page in the WorkOS Dashboard.

The Admin Portal remains branded per environment, not per application.

Applications are created and managed in the Applications section of the WorkOS Dashboard.

Once created, each application exposes its own configuration surface:

• Client ID – a unique identifier for this application, used when initiating authentication flows.
• Redirect URIs – the endpoints AuthKit will return users to after authentication. Password resets, sign-in flows, and invitation links automatically route to the correct destination for the application.
• Session policy – configure session lifetimes appropriate for the platform. A mobile app can stay signed in longer; a web app can follow a shorter expiration window. Each application behaves according to platform expectations without affecting the others.
• Credentials and API keys – each application manages its own credentials, making it easier to isolate client configuration while keeping all applications connected to the same identity layer.

The first application listed in the Applications section of the WorkOS Dashboard is the application that was automatically generated for the environment. You can think of this first application as the default application.

Invitations sent via the WorkOS Dashboard are always associated with the environment’s default application.

Invitations sent via the API or User Management widget will preserve the application context of the API key/widget so that the invited user lands in the right place.

iss

The iss claim is the same for all applications in the environment. It will reference the default application’s client id.

client_id

The client_id claim will reflect the client_id for the current application context.

Claims from the application context can be surfaced in the JWT Template.