Auth methods are the components in Stronghold that perform authentication and are responsible for assigning identity and a set of policies to a user. In all cases, Stronghold will enforce authentication as part of the request processing. In most cases, Stronghold will delegate the authentication administration and decision to the relevant configured external auth method (e.g., Kubernetes).
Stronghold EE also supports WebAuthn for passwordless authentication with FIDO2 authenticators and passkeys.
Stronghold EE also supports SAML for browser-based Web SSO through an external SAML 2.0 identity provider.
Having multiple auth methods enables you to use an auth method that makes the most sense for your use case of Stronghold and your organization.
For example, on developer machines, the Userpass is easiest to use. But for servers the AppRole method is the recommended choice.
To learn more about authentication, see the authentication concepts page.
Available auth methods
| Method | Type (auth enable) | Purpose | Editions |
|---|---|---|---|
| AppRole | approle | Authentication of applications and automation with role_id and secret_id. | Stronghold EE, Stronghold CSE |
| JWT | jwt | Login with a JWT whose signature is verified with keys or JWKS. | Stronghold EE, Stronghold CSE |
| OIDC | oidc (jwt plugin) | Browser login through an OIDC provider: GitLab, Keycloak, Kubernetes. | Stronghold EE, Stronghold CSE |
| Kubernetes | kubernetes | Login with a Kubernetes service account token. | Stronghold EE, Stronghold CSE |
| LDAP | ldap | Login with an LDAP or Active Directory account. | Stronghold EE, Stronghold CSE |
| SAML | saml | Browser-based Web SSO through an external SAML 2.0 identity provider. | Stronghold EE |
| Token | token | Login with a Stronghold token. Built in and cannot be disabled. | Stronghold EE, Stronghold CSE |
| Userpass | userpass | Login with a username and password stored in Stronghold. | Stronghold EE, Stronghold CSE |
| WebAuthn | webauthn | Passwordless login with FIDO2 authenticators and passkeys. | Stronghold EE |
| Kerberos | kerberos | Kerberos (SPNEGO) login. See the auth methods API reference. | Stronghold EE |
Multi-factor authentication (TOTP, Multifactor) is not a separate login method: it adds a second factor to the methods above. See 2FA / MFA.
Editions are listed according to the Editions page.
Enabling and disabling auth methods
Auth methods are enabled and disabled with the CLI or the API. To enable the userpass auth method, run the following command:
- Stronghold in Deckhouse Platform
- Stronghold in Linux
d8 stronghold auth enable userpassstronghold auth enable userpassWhen enabled, auth methods are similar to secrets engines:
they are mounted within the Stronghold mount table and can be accessed
and configured using the standard read/write API. All auth methods are mounted underneath the auth/ prefix.
By default, auth methods are mounted to auth/<TYPE>. For example, if you
enable “ldap”, then you can interact with it at auth/ldap. However, this
path is customizable, allowing users with advanced use cases to mount a single
auth method multiple times. To mount the userpass auth method at auth/my-login, run the following command:
- Stronghold in Deckhouse Platform
- Stronghold in Linux
d8 stronghold auth enable -path=my-login userpassstronghold auth enable -path=my-login userpassWhen an auth method is disabled, all users authenticated via that method are automatically logged out.
External auth method considerations
When using an external auth method (e.g., Kubernetes), Stronghold will call the external service at the time of authentication and for subsequent token renewals. If the status of an entity changes in the external system (e.g., an account expires or is disabled), Stronghold denies requests to renew tokens associated with the entity. However, any existing token remain valid for the original grant period unless they are explicitly revoked within Stronghold. Operators should set appropriate token TTLs when using external authN methods.