Authentication

Corteza implements the OAuth2 authentication protocol, where it can act both as a OAuth2 server and as an OAuth2 client, which allows both internal and external authentications.

Basic authentication parameters are configured on the Corteza Admin web application under system settings in the "authentication" section.

Defining Password Constraints

Corteza allows you to define custom password constraints. That enables you to better conform to your security model.

Password constraints are configured on the Corteza Admin web application under system settings in the "Password Constraints" section.

Minimum length

The minimum length parameter allows you to restrict your users from using short, insecure passwords. You can not set the minimum length below 8 characters.

The maximum password length is not configurable and is set to 256 characters.

Minimum number of numbers

The minimum number of numbers allows you to require your users to use numerical characters in their passwords. The requirement is disabled when the value is left at 0.

Minimum number of special characters

The minimum number of special characters allows you to require your users to use special characters in their passwords. The requirement is disabled when the value is left at 0.

The AUTH_PASSWORD_SECURITY .env variable allows you to disable password requirements checking by setting it to false. This is handy for local development where you may not wish to handle complex password constraints.

The option should be disabled for any production deployment. If the password security is disabled, a warning message is displayed in the UI.

Auth Client

An auth client offers a high-level access control over the use of Corteza API and its resources. An auth client is what applications use when their users attempt to authenticate.

You can use Corteza to authenticate third-party applications that support OAuth2/OIDC.

Auth clients can be defined in the Corteza Admin panel, under the system auth clients section.

From there you can:

list the auth clients created inside your Corteza instance,
create a new auth client by clicking on the new button,
edit an existing auth client by clicking on the edit icon next to the auth client,
manage global auth client permissions by clicking on the permissions button.

Base Auth Client Configuration

Base configuration parameters allow you to both identify the auth client, and specify the validity and the scope that the auth client provides.

The trusted checkbox removes the final confirmation step when the user authenticates.

Grant Types

Corteza supports two OAuth2 grant types: authorization code and client credentials.

Table 1. Authentication grant types:

Authorization code

The authorization code grant type is used to authenticate users with the classic OAuth2 flow.

To enable this grant type, select the "will be used to authenticate users (grant type = authorization_code)" option.

Client credentials

The client credentials grant type is the simplified authentication flow. It is normally used to authenticate systems such as external services or applications.

Client credentials grant type requires you to populate the "impersonate user" option. The impersonated user will be used to create the security context of the JWT token.

To enable this grant type, select the "will be used to authenticate machines (grant type = client_credentials)" option.

Authorization Scope

The scope is defined as a series of role memberships that are either permitted, prohibited, or forced on the user when using a specific Corteza auth server.

Permitted roles

Permitted roles define what roles the user is allowed to have when authenticating with this client.

Prohibited roles

Prohibited roles define what roles the user is not allowed to have when authenticating with this client.

Forced roles

Forced roles define what roles the user will have have when authenticating with this client. If the user does not have a forced role, a role will be automatically assigned.

Limit Access

By default, any user can use any auth client. To limit access to specific auth clients, navigate to the auth client and set the "authorize client" access control rule.

If a specific role does not have the authorize client RBAC rule, the underlying users can not authenticate with the given auth client.

DevNote how can I expand on this…