Skip to main content

Authentication

Kreya centralizes authentication management. Often, you only need a few different "authentication configurations" in your projects.

You can add, edit and delete authentication configurations via Project → Authentications.

Supported authentication types​

Kreya supports a range of authentication types out of the box. The authentication values are automatically transmitted in the correct format.

Basic authentication​

To add a basic authentication configuration, choose the type Basic, enter your username and password, then click Save.

Windows authentication Pro / Enterprise​

To use Windows (or any other Kerberos- or NTLM-based) authentication, create a new authentication configuration with the type System credentials (Kerberos/NTLM). Kreya uses the information of the currently logged in user to authenticate to the API.

OAuth2 / OpenID-Connect​

To add an authentication configuration for OAuth2 or OpenID-Connect, choose the type OAuth2 / OpenID-Connect. Enter the required values. Note that depending on your authentication provider and settings, not all fields need to be filled in.

Supported flows​

The following OAuth2 flows are supported:

  • Authorization Code (with and without PKCE)
  • Implicit
  • Client Credentials
  • Resource Owner Password Credentials
  • Device Authorization (Device Code)

Native browser​

Using the native browser opens the default browser of your system instead of Kreya's built-in web window. This approach allows you to leverage browser extensions, password managers, passkeys, and other browser-specific features. However, it requires a localhost redirect URI with an available port to complete the authentication flow.

JWT​

The JWT (JSON Web Token) authentication type allows you to generate a locally signed token on the fly. This is particularly useful during development or testing when you need to simulate a token with specific claims (e.g. roles, permissions, user IDs) without going through a full identity provider flow. You can configure the payload, header, and the secret/private key used for signing.

JWT Profile (RFC 7523)​

The JWT Profile type implements the "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" (RFC 7523). This method is often used for server-to-server authentication where a client needs to access resources without user interaction. Instead of sending a static client secret, the client creates and signs a JWT assertion to request an access token from the authorization server.

Static authentication values​

Select the Static value type if your authentication value changes infrequently, such as an API key. This value will be sent as-is in the HTTP Authorization header.

Google Service Account​

The Google Service Account type allows you to access Google APIs. Simply provide a JSON key file and a scope.

AWS Signature v4​

The AWS Signature v4 type is a protocol for authenticating inbound API requests to AWS services.

Operation based login​

The Login operation authentication type lets you use an existing operation, script or collection in your project to perform a login and extract credentials from the response. This is useful when your API requires a custom login flow (e.g. a POST /login endpoint) that doesn't fit into standard OAuth2 or other built-in authentication types.

How it works​

  1. Select a login operation: Choose any operation, script or collection from your project that performs the login. For example, a REST operation that sends credentials to a /login endpoint.
  2. Choose a credential type: Decide how to extract the authentication value after running the operation; either via a cookie or a templated value.
  3. Automatic execution: Kreya runs the selected operation whenever credentials are missing or expired. The extracted value is then used to authenticate subsequent requests.

Select the Cookie credential type when your login endpoint sets an authentication cookie. After the login operation runs, Kreya inspects the cookie jar for a cookie matching the configured name.

  • Cookie name: Enter the name of the cookie to extract (e.g. session_id or .AspNetCore.Identity). You can also pick from currently present cookies using the chooser button.
  • Automatic expiry: Kreya uses the cookie's own expiration date to determine when re-authentication is needed.
  • Re-authentication: If the cookie is missing or expired, Kreya automatically re-runs the login operation to obtain a fresh cookie.

The cookie value itself is not placed in the Authorization header. Instead, the cookie is kept in Kreya's cookie jar and automatically sent with subsequent requests to matching domains, just like a browser would.

Templated value credential type​

Select the Templated value credential type when your login endpoint returns a custom credential in the response body (e.g. an access token in a JSON response).

The typical workflow looks like this:

  1. Create a login operation (e.g. a POST /login REST call) and attach an operation script that extracts the token from the response and stores it in a user variable: 
    kreya.rest.onCallCompleted(call => {
      const token = call.response.content.token;
      kreya.variables.set('auth_token', token);
    });
  2. In the operation based login configuration, set the Templated value to reference that user variable: 
    Bearer {{ vars.auth_token }}
  3. Kreya runs the login operation, executes the script, and resolves the template to produce the final Authorization header value.

Configuration options:

  • Templated value: A templating expression that builds the authentication value. All Kreya templating features are available, such as environment variables and user variables.
  • Expiry delta: An optional duration that specifies how long the extracted value remains valid. Uses a human-readable format like 1h, 30m, 1.5d 2h, or 3600s. When the expiry is reached, Kreya re-runs the login operation automatically. If left empty, the login operation runs before every request.
  • Preview: After running the login operation, a preview of the resolved authentication value is shown along with its expiry time.

Templating​

You can use templating in authentications like nearly everywhere else. This will save you a lot of time, for example when you have different passwords for each environment.

Storing sensitive information​

Values entered in authentication configurations (such as Basic authentication passwords) are stored in plain-text in the Kreya project. If you share your project, you may want to extract sensitive information. Use the Environment feature and store sensitive information in User specific data. While this still stores your sensitive data in plain text, it will be stored outside of the Kreya project and thus won't be shared.

Using authentication configurations​

To reference an authentication configuration from an operation, simply click the Auth tab and select your desired authentication configuration. Kreya now adds the correct authentication value to the request.