Login flow and federated identity in Atlassian Isolated Cloud

Atlassian Isolated Cloud provides a fully isolated environment for your organisation's Atlassian products. To support scenarios where Isolated Cloud users need to access certain shared Atlassian services that operate outside the isolated boundary, Atlassian implements a stateless federated login model. This page explains how authentication works within Isolated Cloud and how federated identity enables controlled access to commercial Atlassian services.

How authentication works within Isolated Cloud

When a user accesses an Atlassian product hosted in their Isolated Cloud environment (for example, Jira or Confluence), the following occurs:

1. The request arrives at Atlassian's Global Edge and is forwarded to the ingress gateway within the isolated environment.

2. The ingress gateway inspects the request for authentication headers and forwards the request to the authentication service.

3. If the user is not already authenticated, the authentication service redirects the user to their configured SSO identity provider (SAML or OIDC), where the user completes login – including any MFA or organisation-specific requirements.

4. Once the identity provider confirms the user's identity, the authentication service validates the assertion, establishes a session, and mints a User Context Token (UCT).

5. The authenticated request is routed to the appropriate Isolated Cloud backend service.

All identity data, session state, and authentication processing remain within the isolated environment boundary.

Federated login to shared commercial services

Some Atlassian services (such as the Atlassian Support Centre or Atlassian Marketplace) operate outside the Isolated Cloud boundary on Atlassian's commercial platform. To allow Isolated Cloud users to access these shared services without compromising the isolation model, Atlassian uses stateless federated login.

How it works

Stateless federated login treats your Isolated Cloud identity service as an OAuth 2.0/OIDC identity provider for the commercial Atlassian identity service (id.atlassian.com). The process works as follows:

1. User navigates to a shared service: The user visits a commercial Atlassian service (for example, the Support Centre). The service detects that the user is not authenticated.

2. Redirect to login: The user is redirected to the Atlassian login page and enters their email address.

3. Domain lookup: The login service determines from the user's email domain that their identity resides in an Isolated Cloud environment.

4. Isolated Cloud login option presented: The login page displays a button for Isolated Cloud login, in addition to standard commercial login options.

5. OAuth/OIDC flow initiated: When the user selects the Isolated Cloud login option, the commercial identity service initiates an OAuth/OIDC authorisation flow, redirecting the user to the OAuth server within their Isolated Cloud environment.

6. User authenticates within the isolated environment: The user completes authentication against their configured identity provider within the Isolated Cloud (including any SSO and MFA requirements).

7. Token exchange: On successful authentication, the Isolated Cloud OAuth server returns an authorisation code to the commercial identity service. The commercial identity service exchanges this code for an ID token containing minimal claims: specifically, the user ID and Isolated Cloud identifier. No personal data is persisted in the commercial environment.

8. Stateless session created: A stateless session is provisioned in the user's browser. This session contains only the minimum claims required to identify the user and their Isolated Cloud: no personal data is stored outside the isolated boundary.

Session lifetime

Stateless sessions are valid for up to 24 hours. Your organisation's administrator can configure shorter session timeouts within the Isolated Cloud environment, and these custom timeout values are respected by the commercial session.

Data access through the Isolation Gateway

Once a user has an active stateless session, commercial services can retrieve data from the user's Isolated Cloud through the Isolation Gateway:

1. The user loads a page on a commercial service that requires data from their Isolated Cloud.

2. The commercial service reads the Isolated Cloud identifier from the user's stateless session.

3. The commercial service makes a backend request through the Isolation Gateway to the user's Isolated Cloud.

4. The Isolation Gateway forwards the request to the appropriate backend service within the isolated environment only if the specific API endpoint has been explicitly exposed through the gateway.

5. Data is returned to the commercial service and rendered for the user.

Only explicitly allowlisted API endpoints are accessible through the Isolation Gateway. No arbitrary access to Isolated Cloud data is possible from the commercial environment.

Access controls and restrictions

Key security properties

• No user data persisted outside the isolated boundary: Stateless sessions carry no personal data; only opaque identifiers are used in the commercial environment.

• Authentication always occurs within Isolated Cloud: The user's credentials and identity assertions never leave the isolated environment.

• Explicit API allowlisting: Only specifically approved API endpoints are exposed through the Isolation Gateway.

• Configurable session duration: Administrators retain control over session timeout policies within their Isolated Cloud environment.

• Managed domains only: Federated login is only available for users on managed (verified) domains configured in the Isolated Cloud.