LuciadFusion supports two distinct OAuth 2.0 authentication modes: OAuth 2.0 Login and OAuth 2.0 Resource Server. Both modes delegate identity verification to an external identity provider (IdP) such as Keycloak, Microsoft Entra ID, or Auth0. What makes them different is where the authentication flow takes place and how the browser session is managed.

You can set up one of these authentication modes for the LuciadFusion Studio web application, its REST API, and the geospatial services that LuciadFusion publishes, such as OGC WMS, WCS, 3D Tiles, and others. You can make those services accessible without authentication or you can restrict them to authenticated users. The choice of authentication mode determines which clients can reach those authenticated services.

OAuth 2.0 Login

In OAuth 2.0 Login mode, LuciadFusion acts as an OAuth 2.0 client. When a user visits the LuciadFusion Studio web application in the OAuth 2.0 Login mode, the server redirects the browser to the identity provider’s login page. After the user authenticates, the identity provider redirects back to LuciadFusion, which establishes a server-side session for the user.

Use OAuth 2.0 Login when:

  • You want a simple, browser-based single sign-on.

  • You don’t have any services that require authentication.

  • You don’t need programmatic access to the REST API.

See How to configure OAuth 2.0 login mode in LuciadFusion for configuration instructions.

OAuth 2.0 Resource Server

In OAuth 2.0 Resource Server mode, LuciadFusion validates a bearer token on every incoming request. LuciadFusion doesn’t redirect users to a login page. Instead, clients obtain a token from the identity provider and include it in each request. In the OAuth 2.0 Resource Server mode, the LuciadFusion Studio web application uses the Authorization Code + PKCE flow for this.

Because the server doesn’t maintain session state, this mode is stateless: each request is authenticated independently. Any client that can include an Authorization: Bearer header can access authenticated endpoints.

Use OAuth 2.0 Resource Server when:

  • You want a stateless, token-based architecture.

  • You have services that require authentication.

  • You need programmatic access to the REST API.

Choosing between the two modes

OAuth 2.0 Login OAuth 2.0 Resource Server

Authentication flow

Authorization Code (server-side)

Authorization Code + PKCE (browser-side)

Session management

Server-side session cookie

Stateless — bearer token per request

Authenticated geospatial services

Not supported

Any client with a valid bearer token

REST API access

Browser session only

Any client with a valid bearer token

Recommended for

Browser SSO with services that don’t require authentication

Deployments with authenticated services