Authenticating users

This document covers all aspects of user authentication in Eclipse Che, both on the Che server and in workspaces. This includes securing all REST API endpoints, WebSocket or JSON RPC connections, and some web resources.

All authentication types use the JWT open standard as a container for transferring user identity information. In addition, Che server authentication is based on the OpenID Connect protocol implementation, which is provided by default by Keycloak.

Authentication in workspaces implies the issuance of self-signed per-workspace JWT tokens and their verification on a dedicated service based on JWTProxy.

Authenticating to the Che server

Authenticating to the Che server using other authentication implementations

This procedure describes how to use an OpenID Connect (OIDC) authentication implementation other than Keycloak.

  1. Update the authentication configuration parameters that are stored in the file (such as client ID, authentication URL, realm name).

  2. Write a single filter or a chain of filters to validate tokens, create the user in the Che dashboard, and compose the subject object.

  3. If the new authorization provider supports the OpenID protocol, use the OIDC JS client library available at the settings endpoint because it is decoupled from specific implementations.

  4. If the selected provider stores additional data about the user (first and last name, job title), it is recommended to write a provider-specific ProfileDao implementation that provides this information.

Authenticating to the Che server using OAuth

For easy user interaction with third-party services, the Che server supports OAuth authentication. OAuth tokens are also used for GitHub-related plug-ins.

OAuth authentication has two main flows:


Default. Delegates OAuth authentication to Keycloak server.


Uses built-in Che server mechanism to communicate with OAuth providers.

To switch between the two implementations, use the che.oauth.service_mode=<embedded|delegated> configuration property.

The main REST endpoint in the OAuth API is /api/oauth, which contains:

  • An authentication method, /authenticate, that the OAuth authentication flow can start with.

  • A callback method, /callback, to process callbacks from the provider.

  • A token GET method, /token, to retrieve the current user’s OAuth token.

  • A token DELETE method, /token, to invalidated the current user’s OAuth token.

  • A GET method, /, to get the list of configured identity providers.

Using Swagger or REST clients to execute queries

The user’s Keycloak token is used to execute queries to the secured API on the user’s behalf through REST clients. A valid token must be attached as the Request header or the ?token=$token query parameter.

Access the Che Swagger interface at https://che-host:che-port/swagger. The user must be signed in through Keycloak, so that the access token is included in the Request header.

Authenticating in a Che workspace

Workspace containers may contain services that must be protected with authentication. Such protected services are called secure. To secure these services, use a machine authentication mechanism.

JWT tokens avoid the need to pass Keycloak tokens to workspace containers (which can be insecure). Also, Keycloak tokens may have a relatively shorter lifetime and require periodic renewals or refreshes, which is difficult to manage and keep in sync with the same user session tokens on clients.

che authentication inside the workspace
Figure 1. Authentication inside a workspace

Creating secure servers

To create secure servers in Che workspaces, set the secure attribute of the endpoint to true in the dockerimage type component in the devfile.

Devfile snippet for a secure server
  - type: dockerimage
      - attributes:
          secure: 'true'

Workspace JWT token

Workspace tokens are JSON web tokens (JWT) that contain the following information in their claims:

  • uid: The ID of the user who owns this token

  • uname: The name of the user who owns this token

  • wsid: The ID of a workspace which can be queried with this token

Every user is provided with a unique personal token for each workspace. The structure of a token and the signature are different from what they are in Keycloak. The following is an example token view:

# Header
  "alg": "RS512",
  "kind": "machine_token"
# Payload
  "wsid": "workspacekrh99xjenek3h571",
  "uid": "b07e3a58-ed50-4a6e-be17-fcf49ff8b242",
  "uname": "john",
  "jti": "06c73349-2242-45f8-a94c-722e081bb6fd"
# Signature
  "value": "RSASHA256(base64UrlEncode(header) + . +  base64UrlEncode(payload))"

The SHA-256 cipher with the RSA algorithm is used for signing JWT tokens. It is not configurable. Also, there is no public service that distributes the public part of the key pair with which the token is signed.

Machine token validation

The validation of machine tokens (JWT tokens) is performed using a dedicated per-workspace service with JWTProxy running on it in a separate Pod. When the workspace starts, this service receives the public part of the SHA key from the Che server. A separate verification endpoint is created for each secure server. When traffic comes to that endpoint, JWTProxy tries to extract the token from the cookies or headers and validates it using the public-key part.

To query the Che server, a workspace server can use the machine token provided in the CHE_MACHINE_TOKEN environment variable. This token is the user’s who starts the workspace. The scope of such requests is restricted to the current workspace only. The list of allowed operations is also strictly limited.