How OpenSearch Dashboards SSO with authentik works
If your platform team runs OpenSearch Dashboards and wants users to sign in with authentik instead of local accounts, the supported method is OpenID Connect, configured in the OpenSearch Security plugin and set up from the authentik OpenSearch guide in the integrations catalog. In this model authentik is the identity provider that authenticates users and issues tokens, and OpenSearch Dashboards and the Security plugin trust those tokens and map the identity to OpenSearch roles. Local accounts can remain for break-glass access, so plan which administrator accounts stay available if authentik is unreachable.
For users, the change is a single sign-on redirect to authentik in place of the Dashboards login form, with MFA and password policy enforced in authentik. For administrators, the work moves to two places: authentik gets an OpenID Connect provider and application for Dashboards, and the OpenSearch cluster gets the Security plugin's OIDC authentication settings. Group membership from authentik arrives as a claim, and the Security plugin converts that claim into backend roles that drive access to indices and tenants. Each side needs its own review, because a mismatch in redirect URIs or claim names blocks sign-in without a clear error on the other side.
Both products are open source. OpenSearch and its Security plugin are released under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe any paid edition, so the Security plugin's OIDC support does not require a commercial license. authentik's code is mostly under the MIT license, while code in its enterprise directory falls under a separate enterprise license, and the authentik pricing page lists the options separately. Confirm each setting name, such as the client ID, issuer URL and roles claim key, against the authentik OpenSearch guide and the OpenSearch security documentation for your exact versions before you rely on this outline.
What you need in place before configuring OpenSearch Dashboards SSO
Five things have to be ready before any OIDC settings are touched: the OpenSearch cluster, the authentik instance, its supported version, the group structure that feeds backend roles, and the Dashboards endpoint. Each one is a separate decision, and a gap in any of them usually shows up as a failed login or an empty role set.
OpenSearch cluster with Security enabled
The OpenID Connect settings belong to the OpenSearch Security plugin, so the cluster must run with that plugin enabled and TLS in place for node and client traffic. Confirm the exact OpenSearch version you run against the OpenSearch releases page and its maintenance status before scoping, because a version in maintenance receives only bug and security fixes. Check the security plugin first, since Dashboards cannot delegate sign-in to authentik without it.
Reachable authentik issuer URL
Dashboards discovers authentik's OpenID configuration from the issuer URL, so the host name must resolve and answer over HTTPS from the Dashboards servers and from users' browsers. Confirm that the issuer served by your authentik instance matches the provider you configure in authentik, including the application slug in the path. A mismatch here often looks like a sign-in loop rather than a clear error.
Supported authentik release line
The authentik security policy lists 2026.5.x and 2026.8.x as the supported lines receiving security fixes, and the project announces security releases at least 24 hours in advance. Run one of those lines before you configure the integration, and plan a window for the next security release. If your instance runs an older line, upgrade first so the provider settings you document will still hold.
Groups that map to backend roles
Backend roles in OpenSearch come from a group claim in the token, so the authentik groups must exist before you configure the claim mapping. Decide which groups grant read access, which grant administration and which belong to a tenant, and keep the names stable because OpenSearch role mappings refer to them. Ask the people who own the Dashboards tenants to approve the list before it goes into the mapping.
Dashboards DNS name and certificate
The redirect URI registered in authentik must match the exact scheme, host and path that Dashboards presents, including any reverse proxy in front of it. Issue a certificate for that name from a CA your users' browsers and the Dashboards servers trust, and avoid changing the host name after go-live without updating the redirect URI. Record the host name in your change request so the authentik and OpenSearch sides are reviewed together.
Access to security configuration
Changes to OpenID Connect settings and role mappings are made in the OpenSearch security configuration, which needs an admin certificate or an equivalent admin identity. Confirm who holds that access, how it is recorded, and that a local admin path exists so you can recover if the OIDC settings lock out every user. Test this path before you begin, because an unrecoverable lockout is the most expensive mistake in this integration.
The configuration sequence for authentik and OpenSearch Dashboards
This sequence connects authentik to OpenSearch Dashboards over OpenID Connect so that users sign in once, receive backend roles from their groups, and see only the tenants and indices their role allows. Each step ends with a check you can run before moving on.
Create the OpenID Connect provider and application
An authentik administrator creates an OAuth2/OIDC provider and an application for OpenSearch Dashboards, following the authentik OpenSearch guide for the exact provider type, client type and redirect settings. Record the client ID, the client secret and the issuer URL, and keep the secret out of shared documents. Take the field names from the guide, not from memory, because they change between authentik releases. The step is done when the application appears in the authentik library and the provider shows the issuer URL you recorded.
Define groups and scopes for the token
Decide which authentik groups will map to OpenSearch backend roles, such as analysts, administrators and tenant owners, and confirm that the scopes configured on the provider include the claims that carry group membership. Add a test user to one group only. The check is a decoded ID token or userinfo response that contains the expected group claim with the exact group name. If the claim is missing or uses a different name than the guide describes, fix the scope or property mapping before going further.
Configure the OpenSearch Security plugin for OpenID Connect
On each OpenSearch node or in the security configuration your deployment uses, add an OpenID Connect authentication domain that points to the authentik issuer, with the client ID and secret from step one. Confirm the exact configuration keys and file locations in the OpenSearch security documentation for your version. Make sure the nodes can reach the issuer over TLS and trust its certificate. The check is that the discovery document at the issuer's well-known path loads from an OpenSearch node and that the security configuration applies without errors in the cluster logs.
Set the OpenSearch Dashboards OIDC settings and redirect URI
In the OpenSearch Dashboards configuration, enable OpenID Connect authentication, set the issuer and client details to match authentik, and register the Dashboards callback URL exactly as the authentik provider expects it. A mismatch between the redirect URI in authentik and the one Dashboards sends is the most common cause of failed sign-ins, so compare the two strings character by character. The check is that the Dashboards login page redirects to authentik and returns to Dashboards after a successful sign-in.
Map group claims to backend roles
In the OpenSearch security configuration, map each authentik group claim value to one or more OpenSearch backend roles. Keep the mapping in version-controlled files where your team can review changes. Start with a small set of roles that match your access model, and avoid mapping broad groups to administrative roles. The check is that a test user in one group receives exactly the backend roles you mapped to that group, which you can confirm with the security plugin's user information view or API.
Define tenants and role mappings
Create the OpenSearch tenants that separate saved objects such as dashboards, visualizations and index patterns, then bind each role to the tenants and index permissions it needs. Confirm in the OpenSearch security documentation how multi-tenancy is enabled for your version and whether a shared global tenant is used. Plan which teams own which tenants before you configure them, because changes later are harder to audit. The check is that each role lists only the tenants and index patterns you intended.
Test a non-admin login
Sign in as a user from a non-administrative group in a private browser session and confirm the user sees only the index patterns, dashboards and tenant that the role allows. Try an action outside the role, such as opening a restricted index or a tenant the user should not reach, and confirm it is denied. Check the OpenSearch audit log for the login and the denied request. The step is done when the non-admin results match the access model written in the previous step.
Keep a local admin path for recovery
Keep a local OpenSearch internal user with administrative rights and a credential stored in your secrets manager, so that an administrator can still reach the cluster if authentik or the OIDC configuration is unavailable. Test that this account can sign in to Dashboards with the authentik path disabled in a non-production environment. Document who holds the credential and how it is rotated. The check is a successful local admin login in the test environment and a written recovery procedure that the operations team has reviewed.
How authentik claims map to OpenSearch roles and tenants
This table compares each authentik claim or source attribute with the OpenSearch Security element it feeds, plus who should decide its value. Read the example rows as illustrative patterns: the group names and role names shown are chosen by your organization, and the mapping must be confirmed against the authentik OpenSearch guide and your cluster's security configuration before go-live.
| Claim or attribute | OpenSearch element | Illustrative example | Who owns the decision |
|---|---|---|---|
| User identifier claim (sub or preferred_username) | OpenSearch user name recorded in audit logs and security index | preferred_username maps to a user such as jdoe, so audit entries name the person | Identity team with the SOC or platform lead, confirmed in the authentik provider settings |
| Groups claim | Backend roles attached to the authenticated user | A groups claim listing opensearch-admins and soc-analysts is passed through as backend roles | Identity team defines group membership; platform team confirms which claim name the provider emits |
| Admin-level group (illustrative: opensearch-admins) | Role mapping to all_access or a custom administrative role | Members of the admin group receive cluster-wide permissions, so keep this group small | CISO or security owner approves membership; platform team writes the role mapping |
| Read-only analyst group (illustrative: soc-analysts) | Role mapping to a custom read role limited to specific index patterns | Analysts can search alert indices but cannot change index settings or security configuration | Security operations lead sets scope; platform team maintains index patterns and role definitions |
| Tenant membership (illustrative: tenant per business unit) | Tenant assigned through the Dashboards multi-tenancy settings and role permissions | A group such as tenant-finance-ops grants access to a shared tenant with saved objects and dashboards | Data owners decide who sees each tenant; platform team configures tenants and reviews them periodically |
Why group design in authentik decides who can see which data
The mapping from authentik groups to OpenSearch backend roles controls what a user can read, not only whether the login screen opens. OpenSearch Security provides role-based access control, document-level and field-level security, and field masking, and each of these is evaluated against the roles attached to the authenticated user. When the OpenID Connect claim carrying groups from authentik is mapped to backend roles, a person who lands in a broad group can inherit index patterns, document filters and masked fields they were never meant to see, even though authentication itself worked exactly as designed. Before go-live, review every authentik group that will emit into the claim and list the OpenSearch roles, index permissions and security filters each one unlocks. Treat any group that grants wildcard index access as a finding to resolve, not a convenience to keep.
Keep group membership in authentik the single source of truth, and do not add OpenSearch-side users or role mappings that bypass it, because two sources of membership will drift apart during offboarding and reorganizations. Changes made in authentik do not reach OpenSearch instantly. Confirm in your own environment whether a removed group is dropped at the user's next login or only when the session token refreshes, and set your session lifetimes with that gap in mind. The Security plugin also supports user impersonation, which lets an authorized administrator act as another user and therefore bypass that user's own access boundaries. Restrict impersonation to a short list of named administrators, do not map it to a broad group, and make sure those impersonation events appear in the audit logs your SOC reviews.
Security settings to lock down in this integration
The OpenSearch Dashboards sign-in path crosses three trust boundaries: the browser, authentik and the OpenSearch cluster. Each card below covers one control that keeps those boundaries closed, and each one is worth checking against your own authentik version and cluster configuration before go-live.
Encrypt every hop with TLS
Dashboards, the OpenSearch cluster and authentik should only talk to each other over TLS, including the OpenID Connect discovery and token calls that Dashboards makes to authentik. Confirm that the Dashboards opensearch.ssl settings and the cluster node and client certificates are in place, and that the certificate chain Dashboards trusts includes the authentik hostname. A plaintext hop here can expose tokens and session data.
Keep the client secret out of the repository
The OpenID Connect client secret lets Dashboards exchange authorization codes, so anyone who reads it can impersonate the client. Store it in a secrets manager or an environment variable injected at deploy time, not in opensearch_dashboards.yml committed to version control. Rotate it when staff with access change, and confirm that backups and container images do not carry the plain value.
Allow only exact redirect URIs
Register the Dashboards callback URL as a full, exact value in the authentik provider, including scheme, hostname and port. Avoid wildcards and do not reuse one provider for unrelated applications. Test the login flow from each hostname that reaches Dashboards, such as an internal alias and a load balancer name, because each one needs its own permitted callback.
Scope backend roles to least privilege
Map authentik group claims to OpenSearch backend roles only as broadly as each team needs. For sensitive indices, add document-level or field-level security and field masking in the Security plugin roles so that a valid login does not expose every document. Review the role mapping whenever a group in authentik changes, since a renamed or reused group can silently widen access.
Enable and review audit logs
Turn on OpenSearch audit logging for authentication failures, privilege changes and access to sensitive indices, and forward those events to a store that the platform team cannot silently edit. On the authentik side, review sign-in events and provider changes, including edits to the OpenSearch provider and its group bindings. Confirm the retention period with your security team before relying on either log for an investigation.
Protect admins with MFA and break-glass
Require a second factor for administrator groups through authentik policy bindings, and confirm which factor types and enforcement options your authentik version supports before you rely on them. Keep one local OpenSearch admin account, stored offline with a tested recovery procedure, so the cluster can be reached if authentik or its certificates fail. Document who may use the break-glass account and how its use is logged.
Choosing a tenancy model for teams sharing one OpenSearch cluster
This model fits when each team owns its indices, saved objects and dashboards, and rarely needs to see another team's work. Each team gets its own OpenSearch Dashboards tenant, so saved searches, visualizations and index patterns stay separate. The authentik side is the simplest of the three options: one group per team, with that group's name carried in the OIDC group claim and matched to a backend role in the security plugin.
- Group design: Create one authentik group per team, keep membership managed by the team's directory or lifecycle process, and avoid nesting groups that would grant unintended roles.
- Role configuration: Map each backend role to an OpenSearch role that grants index patterns for that team's indices and assigns the matching tenant with read and write permissions.
- Index boundaries: Name indices with a team prefix and restrict each role to that pattern, so a misnamed index does not leak data across teams.
- Operational cost: Each new team means a new group, role and tenant, which adds recurring review work as teams form and merge.
- Private defaults: Confirm in the OpenSearch security documentation for your version how the default tenant behaves and whether users see it automatically.
Confirm tenant defaults and permission syntax against the OpenSearch security documentation for the version you run before writing role definitions.
This model fits when several teams read the same operational dashboards, such as platform health or shared service views, but only a small group should edit them. One shared tenant holds the common saved objects. Read access goes to most users, and write access is limited to a curator role. The difficulty lies in keeping the shared tenant from becoming an unowned area where anyone's changes affect everyone.
- Group design: Use a read group for all consumers and a separate curator group for the people who maintain dashboards, and do not place curators in the read group by default.
- Role configuration: Grant the read group read-only permissions on the shared tenant and the curator role write permissions on it, scoped to the index patterns those dashboards need.
- Data scope: Restrict index patterns to data every reader is cleared to see, since dashboards in a shared tenant can expose fields across teams.
- Change control: Export saved objects through a documented review step rather than letting curators edit production dashboards directly.
- Operational cost: Curators carry ongoing ownership of shared content, and each new shared dashboard needs a named owner and a review process.
Confirm how read-only tenant permissions and saved object edits are enforced in your OpenSearch version, because the exact permission names change between releases.
This model fits when datasets have incompatible classifications, such as regulated personal data alongside general operational logs, or when different teams must be administered and audited independently. A separate cluster removes shared storage, shared snapshots and shared node-level access from the picture. Tenants and roles inside one cluster are a logical boundary, while a separate cluster is a physical one, and auditors often treat them differently.
- Group design: Create authentik groups per classification boundary and give each cluster its own OIDC client, so a user's access to one cluster does not depend on group logic in the other.
- Role configuration: Configure the security plugin independently on each cluster, with its own roles, tenants and audit log settings.
- Infrastructure: Each cluster needs its own nodes, TLS material, snapshot repository and upgrade schedule, which can differ by data classification.
- Operational cost: Two or more clusters multiply patching, capacity planning, backups and monitoring, and the cost rises with each additional classification boundary.
- Audit scope: Confirm with your assessor which controls apply to each cluster and whether the classification split reduces the scope of the sensitive one.
Before committing to this model, ask your team to estimate the recurring operations effort for each cluster and confirm the classification rules with the data owner and assessor.
Common failures when signing in to OpenSearch Dashboards with authentik
This table lists the failures teams most often hit when connecting OpenSearch Dashboards to authentik over OpenID Connect, with the likely cause and the check that confirms each fix. Work through the rows in order, since a broken redirect or unreachable issuer blocks every later test. Treat the fixes as starting points and confirm the exact settings against the authentik OpenSearch guide and your own cluster configuration.
| Symptom | Likely cause | Fix and confirming check |
|---|---|---|
| Authentication fails after the authentik login page with a redirect error | The redirect URI registered in the authentik provider does not match the callback URL that Dashboards sends | Copy the callback URL from the Dashboards OIDC settings exactly, including scheme, host, port and path, into the authentik provider. Confirm by starting a fresh login in a private browser window. |
| Dashboards fails to start or the login button never appears | The issuer or discovery URL is unreachable from the Dashboards or cluster network | Test the discovery endpoint from the Dashboards host and from each cluster node, not only from your workstation. Confirm that the same URL resolves and returns a response from every host that needs it. |
| Token exchange or discovery fails with a TLS or certificate error | The Dashboards or cluster host does not trust the certificate presented by the authentik endpoint, often because an internal certificate authority is in use | Add the issuing certificate authority to the trust store used by Dashboards and the Java or Node runtime it relies on. Confirm with a TLS handshake test from the same host against the authentik URL. |
| Users sign in successfully but see no indices or dashboards | No backend roles were mapped from the token, so the security plugin grants no index permissions | Check that the roles claim reaches Dashboards and that the mapping to backend roles exists in the security configuration. Confirm by inspecting the signed-in user's security information page for backend roles. |
| Expected group mapping does not apply | Group names in authentik differ in case, prefix or format from the values the role mapping expects | Compare the exact group names in authentik with the mapping entries, character by character. Confirm by reviewing the claim value in a test token or the user's group list before editing mappings. |
| Groups or roles are missing from the login, while the user exists | The groups scope was not requested, or the authentik property mapping that adds the claim is not attached to the scope | Confirm the scopes configured in Dashboards and in the authentik provider include the scope that carries groups. Confirm by checking that the claim appears in the ID token or user info response. |
| Administrators cannot sign in after a failed configuration change | An OIDC change disabled or broke the only account with admin rights, and no local admin path was kept | Keep a locally defined admin account and a tested recovery procedure before changing authentication settings. Confirm by testing the local admin login on a non-production cluster before the production change. |
| Logins succeed for some users but not others | Users lack the group membership needed for the mapped backend role, or their accounts are inactive in authentik | Compare a working user and a failing user in authentik, including group membership and active status. Confirm by repeating the login after correcting group membership, then reviewing the backend roles shown for each user. |
Questions teams ask before they configure OpenSearch SSO with authentik
Does OpenSearch SSO with authentik require a paid OpenSearch or authentik edition?
No paid OpenSearch edition is required. The OpenSearch FAQ describes OpenSearch as released under the Apache License, Version 2.0, and does not describe any paid edition. The OpenID Connect integration uses the open-source authentik server and the OpenSearch Security plugin. authentik's Enterprise features, such as the Entra ID and Google Workspace integrations, are not needed for OIDC sign-in to OpenSearch Dashboards. Confirm the license terms of the specific OpenSearch and authentik versions you plan to run, and check authentik's licensing before you finalize the architecture, since enterprise code sits under a separate license.
What drives the cost and effort of an OpenSearch and authentik SSO integration?
The main drivers are the group design, the number of tenants, the existing OpenSearch Security configuration, and the TLS and certificate work. Each group that maps to a backend role or tenant adds design, configuration and testing effort. A cluster that already has roles, role mappings and tenants needs a migration plan rather than a fresh setup. Certificate handling between authentik, the OpenSearch nodes and Dashboards can take longer than expected in environments with internal certificate authorities. Testing scope also matters: a single admin test is much smaller than a matrix of user groups, tenants and failure cases. Ask any partner for a quote built from these items in writing.
How long does an OpenSearch SSO integration with authentik take?
No duration is supplied for this integration, so the written scope document is the source for the timeline. It should list the group design workshop, the authentik provider and application setup, the OpenSearch Security configuration, the tenant and role mapping, the test plan, and the cutover steps. Timelines depend mainly on how many groups and tenants are in scope, how many environments (development, test and production) must be configured, and whether the team has done this before. Ask for the timeline to be tied to specific deliverables and acceptance tests.
What must our team provide before the integration work starts?
Plan to provide four things. First, an authentik administrator who can create the OpenID Connect provider, the application and the group claims. Second, OpenSearch administrator access so the Security plugin settings and role mappings can be configured and tested. Third, decisions on group design: which authentik groups map to which OpenSearch backend roles and tenants. Fourth, a set of test users covering each intended role, plus at least one user who should be denied access. Also confirm who owns the TLS certificates and the reverse proxy in front of Dashboards, because both affect the redirect and certificate settings.
Can our own team configure OpenSearch SSO with authentik without an outside partner?
Yes, if your staff can run the OpenSearch Security configuration and administer authentik. The work involves OIDC client settings, claim mapping to backend roles, role and tenant definitions, and TLS configuration, so the team needs people comfortable with each area. A partner is most useful when the group design is complex, the cluster already has a large security configuration, or the team has no one who has changed OpenSearch Security settings before. Whichever path you choose, keep a documented admin login path for recovery in case SSO fails during configuration.
How do OpenSearch upgrades affect the authentik SSO integration?
Upgrades can change Security plugin behavior, so each OpenSearch minor or major version needs a retest of the sign-in flow, group claims and role mappings. OpenSearch releases a new minor version about every eight weeks, and its releases page describes a maintenance policy: versions receive bug fixes and security patches but no new features while in maintenance, and version 1 reached end of life on May 6, 2025. Confirm the current maintenance dates on the OpenSearch releases page before you schedule an upgrade, and rerun your test users after each change. Keep the authentik version on its supported line as well, and check the authentik security policy for the supported versions.
Which OpenSearch multi-tenancy and role features does the authentik mapping depend on?
The integration maps identity provider groups from the token claims to OpenSearch backend roles, and those roles determine which indices, tenants and dashboards a user can reach. The OpenSearch Security plugin provides role-based access control, document-level and field-level security, field masking and audit logs, so the mapping should be designed with those controls in mind. Engineers should check that the group claim reaches Dashboards as expected, that role mappings are tested per group, and that tenant access is verified separately from index access. Confirm each setting against the OpenSearch security documentation for your version.
How DeployOpen scopes and delivers OpenSearch Dashboards SSO with authentik
DeployOpen plans and builds the authentik and OpenSearch Dashboards sign-in path inside infrastructure you control, from the OpenID Connect provider in authentik to the security plugin settings and role mapping in OpenSearch. Work starts from a written scope, and the handover covers configuration, tests and the operating notes your team needs after go-live.
How we scope
- We confirm which OpenSearch and authentik versions your environment runs before any design work starts.
- We map which authentik groups should become OpenSearch backend roles, and who approves that mapping.
- We agree in writing whether the work covers tenants, dashboards access, fallback admin accounts and audit logging.
How we build
- We configure the OpenID Connect provider and application in authentik, including redirect URIs for your Dashboards hostname.
- We set the OpenSearch security plugin OIDC settings and group claim handling in a non-production cluster first.
- We test sign-in, role assignment and tenant visibility with a defined set of test users from each group.
How we hand over
- You receive the configuration as delivered, with each authentik and OpenSearch setting documented and explained.
- You receive a test record showing which groups map to which backend roles and which tenants they can reach.
- You receive a runbook covering certificate renewal, secret rotation and how to recover access if the identity provider is down.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer work can cover re-testing after OpenSearch or authentik version changes that affect the OIDC path.
- Quotes follow from the written scope, so ask for the components, environments and tests each item includes.
