Project AuthenticationAuth Basics
Project Authentication

Auth Basics

AuthBasics

MPO Version: 1.3.0

Defines the fundamental authentication configuration for the project. These settings determine the authentication method(s) used across all services, including token-based, SSO, remote service, or API key authentication.

interface AuthBasics = {
  JWTAuthentication : JWTAuth;
  ssoAuthentication : SSOAuth;
  apiKeyAuthentication : APIKeyAuth;
  httpSettings : AuthHttpSettings;
  cookieSettings : CookieSettings;
}
FieldDescription
JWTAuthenticationConfiguration for JWT-based authentication, where the project issues and verifies its own JSON Web Tokens. This is the recommended authentication method in Mindbricks for secure, scalable identity management.
ssoAuthenticationSettings for enabling Single Sign-On (SSO) integration with external identity providers, typically used by enterprise users. Mindbricks does not generate an SSO server but supports integration with your organization's existing SSO infrastructure.
apiKeyAuthenticationEnables API key-based authentication for accessing the project's services. This method can be used either as the primary authentication mechanism or as a secondary option alongside others.
httpSettingsDefines the HTTP configuration of the auth service. Primarily includes the port on which the auth service will accept HTTP requests.
cookieSettingsUse this settings to arrange the allowed domains of your applications cookie. Note thar a mindbricks service cookie is set as secure:true, httpOnly:true, sameSite:none, but domain is set according to the login requesrt hos if it is in. the allowed list or defaults.

JWTAuth

MPO Version: 1.3.0

Defines the configuration for JWT-based authentication, where the project issues and verifies its own JSON Web Tokens. This is the recommended authentication method in Mindbricks due to its stateless nature and scalability.

interface JWTAuth = {
  useJWTForAuthentication : Boolean;
  configuration : JWTAuthConfig;
}
FieldDescription
useJWTForAuthenticationIndicates whether JWT authentication is enabled for the project.
configurationThe configuration object for JWT authentication. Leave it null if useJWTForAuthentication is false.

JWTAuthConfig

MPO Version: 1.3.0

Defines the configuration details for JWT-based authentication. This object is used when useJWTForAuthentication is set to true. It includes token and key refresh periods.

interface JWTAuthConfig = {
  tokenPeriodInDays : Integer;
  keyRefreshPeriodInDays : Integer;
}
FieldDescription
tokenPeriodInDaysSpecifies the lifespan of each JWT token, in days. After this period, the token will expire and require reauthentication.
keyRefreshPeriodInDaysSpecifies how often the JWT signing key pair (private/public) should be regenerated, in days. Regular key rotation enhances security.

SSOAuth

MPO Version: 1.3.0

Defines the Single Sign-On (SSO) configuration for the project. This allows users to authenticate via their organization's identity provider using standard SSO protocols. Mindbricks integrates with external SSO providers but does not generate or host its own SSO server.

interface SSOAuth = {
  useSSOForAuthentication : Boolean;
  configuration : SSOAuthConfig;
}
FieldDescription
useSSOForAuthenticationSpecifies whether SSO is enabled as an authentication method for the project. If enabled, users will be able to log in using an external SSO provider.
configurationThe configuration object for the SSO provider. Leave it null if useSSOForAuthentication is false.

SSOAuthConfig

MPO Version: 1.3.0

Defines the configuration for an external SSO provider. This object is used when useSSOForAuthentication is set to true. It includes provider name, token period, endpoints, and profile mapping.

interface SSOAuthConfig = {
  ssoName : String;
  tokenPeriodInMinutes : Integer;
  emailPropertyInProfile : String;
  userNamePropertyInProfile : String;
  ssoUserIdPropertyInProfile : String;
  ssoServerSettings : SSOServerSettings;
}
FieldDescription
ssoNameA human-readable name to identify this SSO provider in your project (e.g., 'corporateSSO' or 'okta').
tokenPeriodInMinutesSpecifies how long a session token issued via SSO remains valid, in minutes. After expiration, the user must be reauthenticated through the SSO server.
emailPropertyInProfileThe field in the SSO profile payload to use as the user's email address. Used for identifying or creating the user record.
userNamePropertyInProfileThe field in the SSO profile payload to use as the user's display name. Used when creating a new user on first login.
ssoUserIdPropertyInProfileThe field in the SSO profile payload that will be used as the unique SSO user ID in Mindbricks. Common defaults are 'sub' or 'id'.
ssoServerSettingsConfiguration of the SSO provider's endpoints and client credentials. Includes authorization, token, user profile, and logout URLs as well as client ID and secret.

SSOServerSettings

MPO Version: 1.3.0

The SSOServerSettings object defines the configuration for a Single Sign-On (SSO) integration, including endpoint URLs and client credentials. These settings enable the service to interact with an external identity provider using OAuth2/OIDC protocols by specifying how to authenticate, retrieve tokens, get user info, and handle logouts.

interface SSOServerSettings = {
  tokenHost : String;
  authPath : String;
  tokenPath : String;
  userInfoPath : String;
  logoutPath : String;
  redirectUrl : String;
  clientId : String;
  clientSecret : String;
}
FieldDescription
tokenHostThe base URL of the SSO provider (e.g., https://auth.example.com). This value is used as the root for building all other endpoint paths.
authPathThe relative path to initiate user authorization on the SSO provider (e.g., /oauth2/authorize).
tokenPathThe relative path to request access tokens from the SSO provider (e.g., /oauth2/token).
userInfoPathThe relative path to fetch the authenticated user's profile information (e.g., /userinfo).
logoutPathThe relative path to perform logout on the SSO provider (e.g., /logout).
redirectUrlThe full callback URL of the client application to which the SSO provider will redirect after login. This URL must match the one registered with the SSO provider.
clientIdThe client identifier issued to your application by the SSO provider. This ID is used to identify your app during the authentication flow.
clientSecretThe secret associated with the client ID, used to authenticate your application with the SSO provider when exchanging tokens.

APIKeyAuth

MPO Version: 1.3.0

Enables API key authentication for the project. When enabled, Mindbricks generates an apiKey data object, management APIs (create, list, delete), and validation endpoints. Secret API keys use the skmbx prefix and allow tokenless, session-based authentication — ideal for server-to-server integrations, AI agents, CI/CD pipelines, and MCP connections. Public API keys are defined in the configuration schema for future support but are not yet implemented.

interface APIKeyAuth = {
  useAPIKeyForAuthentication : Boolean;
  configuration : APIKeyAuthConfig;
}
FieldDescription
useAPIKeyForAuthenticationEnable or disable API key authentication for this project. When true, the auth service will include the apiKey data object and key management APIs.
configurationOptional configuration for API key behavior. When null, defaults to secret-only keys sent in the Bearer header. Set this to customize key types, locations, or names.

APIKeyAuthConfig

MPO Version: 1.3.0

Fine-tune API key authentication behavior. Controls which key types are generated, where keys are located in requests, and custom header/query parameter names. When omitted, Mindbricks defaults to secret-only keys in the Authorization Bearer header with the skmbx prefix — no additional configuration needed for standard usage. Note: public API key fields (publicApiKeyLocation, publicApiKeyName) are reserved for future support and have no effect currently.

interface APIKeyAuthConfig = {
  apiKeyType : APIKeyType;
  secretApiKeyLocation : RequestLocations;
  publicApiKeyLocation : RequestLocations;
  secretApiKeyName : String;
  publicApiKeyName : String;
}
FieldDescription
apiKeyTypeThe type of API keys to generate. 'secret' (default) creates skmbx-prefixed keys that authenticate on behalf of a user and create server-side sessions. 'public' and 'both' options are reserved for future support — only 'secret' is currently implemented.
secretApiKeyLocationWhere secret API keys are sent in HTTP requests. Defaults to 'bearer' (Authorization: Bearer skmbx...). When set to 'header' or 'query', the secretApiKeyName field specifies the header or query parameter name.
publicApiKeyLocationReserved for future support. Where public API keys will be sent in HTTP requests. Defaults to 'query'. Has no effect until public API key support is implemented.
secretApiKeyNameCustom header or query parameter name for secret API keys. Only required when secretApiKeyLocation is not 'bearer'. When location is 'bearer', the skmbx prefix is used for automatic detection and this field is ignored.
publicApiKeyNameReserved for future support. Custom header or query parameter name for public API keys. Has no effect until public API key support is implemented.

APIKeyType

Specifies the type of API key to use. This can be either 'secret', 'public', or 'both'. If not set, the default is 'secret'. If you need to use both secret and public keys, you can set this to 'both'.

const APIKeyType = {
  secret: "secret",
  public: "public",
  both: "both",
};
EnumDescription
secretSecret API key is used in trusted parties to access on behalf of the user to the sensitive data.
publicPublic API key is used to identify the client's public access key. Use public keys if you need to identify the client when you need to identify the client when from a frontend based access to non-sensitive data.
bothBoth secret and public API keys are used. This is useful if you need to use both secret and public keys for the same client.

RequestLocations

An enum type to refer to a specific section of an HTTP request where data (e.g., tokens or parameters) can be located.

const RequestLocations = {
  bearer: "bearer",
  cookie: "cookie",
  header: "header",
  query: "query",
  body: "body",
  urlpath: "urlpath",
  session: "session",
  request: "request",
};
EnumDescription
bearerUse when the data is sent as a Bearer token in the Authorization header. No name is required for this mode.
cookieUse when the data is sent in cookies. The name refers to the cookie's key.
headerUse when the data is sent in a custom HTTP header. The name is the header's name.
queryUse when the data is sent as a query parameter. The name is the name of the query parameter.
bodyUse when the data is sent in the body of the request. The name refers to a property in the request body.
urlpathUse when the data is part of the dynamic URL path (e.g., /users/:id). The name is the parameter name.
sessionUse when the data is extracted from the server-side session object.
requestUse when the data exists directly on the root of the request object.

AuthHttpSettings

MPO Version: 1.3.0

Defines the HTTP configuration of the auth service. Primarily includes the port on which the auth service will accept HTTP requests.

interface AuthHttpSettings = {
  httpPort : Integer;
  routerSuffix : String;
}
FieldDescription
httpPortThe port number that the auth service will use to listen for HTTP traffic. Recommended to use ports in the 3000-3099 range for consistency across microservices.
routerSuffixUse this in your custom deployment if you have any suffix in your auth service url to be removed before evaluated in express router. AI Agents should keep this null.

CookieSettings

MPO Version: 1.3.0

Use this settings to arrange the allowed domains of your applications cookie. Note thar a mindbricks service cookie is set as secure:true, httpOnly:true, sameSite:none, but domain is set according to the login requesrt hos if it is in. the allowed list or defaults.

interface CookieSettings = {
  allowedDomains : String[];
}
FieldDescription
allowedDomainsMindbricks create cookies that is allowed for localhost, and the subdomain of the project in mindbricks.co, the architect may add his own one or more frontend urls, it can be given either as domain like xapp.com or as a subdomain like web.xapp.com