authentik MinIO SSO integration: what it does and the method it uses
A platform team that wants object storage users to sign in through authentik has one decision to make before any configuration: which MinIO edition it will run. authentik's MinIO guide in its integrations catalog configures an OpenID Connect provider on the authentik side, and the same guide warns that the MinIO community repository and legacy community binaries are no longer maintained, with MinIO directing new deployments to AIStor. The minio/minio README says the same and describes AIStor Free and AIStor Enterprise as the alternatives. The minio/minio, minio/operator and minio/mc repositories are archived and read-only. Confirm which edition your organization can support before you build anything on it.
The integration itself is standard OIDC. authentik acts as the identity provider, MinIO acts as the relying party, and the login flow returns an identity token whose claims MinIO maps to policies that govern console and API access. The claim you choose to carry policy information, and the group or attribute that feeds it, is the core design decision: it determines who can reach the web console, who receives read-only or administrative rights, and how a change in an authentik group propagates to storage permissions. Plan the claim names, the authentik provider and application objects, and the MinIO policy names together, and record them in a mapping table that your reviewers can check against the access model.
Because the guide's own warning applies to the community software, a production design should test the edition question with MinIO and your security team before the OIDC settings are finalized. Ask MinIO to confirm the licensing position for your use case, since the community server is released under the GNU AGPL v3.0 and its README says commercial or proprietary use must be validated against AGPLv3 obligations. Ask whether the AIStor path changes the OIDC configuration, the policy model or the console URL. Also confirm how support would be obtained, because the README says community support is best effort through GitHub and Slack and SLA-backed support is available only through AIStor.
Prerequisites for an authentik to MinIO OIDC integration
The integration depends on three systems that must be ready first: a supported authentik deployment acting as the OpenID Connect issuer, a MinIO edition you have chosen to run, and endpoints with valid TLS and DNS. Confirm each item below before you open the provider settings, because gaps in any one of them tend to surface as sign-in failures that look like configuration errors.
Supported authentik version
Run authentik on a release that still receives security fixes. The authentik security policy lists 2026.5.x and 2026.8.x as the supported lines, and the project announces security releases at least 24 hours in advance. Plan a maintenance window so an upgrade does not land in the middle of the MinIO change. Check the current version on the authentik releases page before you start, since the latest release may have moved on from the one you tested.
A MinIO edition decision
Decide which MinIO edition you will run before you build the integration. The MinIO community repositories are no longer maintained, and the legacy community binaries will not receive updates. The authentik MinIO guide directs new deployments to AIStor. Confirm with MinIO which edition fits your licensing, support and distribution needs, and do not assume the community build used in older tutorials is a safe long-term base.
TLS and DNS for every endpoint
Give the authentik issuer, the MinIO console and the MinIO API their own DNS names with valid certificates that clients trust. OpenID Connect redirects and discovery both depend on these names resolving consistently from user browsers, the mc client and MinIO itself. Confirm the certificate chain is complete, and record the exact issuer URL and redirect URIs you will register, because a mismatch in scheme, host or port is the most common cause of failed logins.
Administrative access to MinIO
Have an account with administrative rights on MinIO and a break-glass path before SSO goes live. Once OIDC is enabled, administrators who rely only on federated accounts can be locked out if group claims or policy mappings are wrong. Keep a root or local administrator credential stored in your secrets system, and confirm you can reach the MinIO console and run mc commands with it without going through authentik.
Capacity for the authentik host
Size the authentik host separately from MinIO. The Docker Compose guide calls for at least 2 CPU cores and 2 GB of RAM and positions Compose for test setups and small-scale production. Those figures describe authentik itself, not object storage. MinIO sizing depends on data volume, erasure coding layout and request load, so work it out from your storage design and do not reuse the authentik figure for the MinIO nodes.
Confirmed group and claim design
Agree on the groups in authentik that will map to MinIO policies before you configure the client. Each group name, and the claim that carries it, must match what the MinIO side expects. Write down which groups grant read, write or administrative access, and who approves changes to them. Confirm the mapping with the owners of the storage and identity teams, since a policy that is too broad grants object access that is hard to trace afterward.
How to configure the OIDC provider in authentik and MinIO
This sequence creates an OpenID Connect provider and application in authentik, carries a policy claim in the token, points MinIO at the provider, and confirms that console and API sign-in both map users to the right MinIO policy. Each step ends with a check you can run before moving on.
Confirm the MinIO edition and deployment path
Before touching authentik, decide which MinIO build you will run. The MinIO README states that the community repository is no longer maintained, that legacy community binaries will not receive updates, and that MinIO directs new deployments to AIStor Free or AIStor Enterprise. Confirm the edition, license obligations and support model with MinIO and your legal team, because the authentik MinIO guide assumes an OpenID Connect capable server version. Done means you have a written decision on the edition, the version you will deploy, and the URL where the console and API will be reachable.
Create the OAuth2/OIDC provider in authentik
In the authentik admin interface, create an OAuth2/OIDC provider for MinIO. Set the client type, the signing key, and the redirect URIs for both the MinIO console callback and the API callback, using the exact URLs from the authentik MinIO guide and your own hostnames. Record the client ID and client secret in your secrets store. Done means the provider saves with the redirect URIs you planned and the scopes include openid, profile, email and any group or policy scope you map.
Add a claim that carries the MinIO policy name
Create a property mapping in authentik that adds a claim, for example a custom claim naming the MinIO policy, derived from group membership or a user attribute. MinIO maps this claim to its own policies, so the claim value must match a policy name that already exists on the MinIO side. Bind the mapping to the provider's scopes. Done means a test token issued by authentik for a test user contains the claim with the expected value, which you can check by decoding the ID token from a test login.
Create the application and bind access policies
Create an authentik application that points to the MinIO provider, and bind a policy or group that controls which users may sign in. Keep a small test group for the first rollout. Keep a local MinIO root or break-glass account documented and tested before enforcing SSO, so that an authentik outage does not lock out administrators. Done means an authorized test user can reach the authentik application launcher and an unauthorized user is denied at the authentik layer.
Configure MinIO's OpenID settings
Set MinIO's OpenID configuration to the authentik discovery URL for the provider, the client ID and secret, the redirect URI, and the claim name that carries the policy. Follow the authentik MinIO guide for the exact configuration keys and environment variables for your MinIO version, and confirm each key name against MinIO's own documentation for that release. Restart MinIO and check its logs for errors on startup. Done means MinIO starts cleanly and reports the OpenID provider as loaded without warnings about discovery or claim parsing.
Verify the discovery document and token claims
Fetch the authentik OpenID discovery document for the provider from a host that can reach it, and confirm the issuer, authorization endpoint, token endpoint and JWKS URI resolve and match what MinIO is configured to use. Then sign in as the test user and confirm the issued token contains the policy claim with the expected value. Done means the discovery document loads over HTTPS, the issuer string matches MinIO's configuration exactly, and the claim value is the one you planned.
Test console login and API access
Sign in to the MinIO console through authentik as the test user and confirm that the console shows only the buckets and actions allowed by the mapped policy. Then test API access with a short-lived credential obtained through the OpenID flow, and confirm that an allowed operation succeeds while a disallowed one is refused. Repeat with a user in a second group to confirm policy separation. Done means each test user gets the expected access in both the console and the API, and denials are logged on the MinIO side.
Record the configuration and the break-glass path
Document the authentik provider settings, the claim mapping, the MinIO configuration keys, the redirect URIs, the test users and expected policies, and the break-glass procedure. Store the client secret in your secrets manager and set a rotation owner. Confirm with your security team how the break-glass account is protected and tested. Done means an operator who did not build the integration can repeat the test steps from the document and reach the same results.
Mapping authentik claims to MinIO policies
This table compares each step between an authentik claim and a MinIO policy, from the attribute or group that starts the mapping to the access check MinIO applies. Read it as a checklist: the claim name and policy name must match exactly on both sides, and any gap leaves the user with no access. Exact claim names should be confirmed against the authentik MinIO integration guide before you configure anything.
| Step | What to set | What to confirm or watch for |
|---|---|---|
| Source attribute | Pick the authentik group or user attribute that represents the access tier, such as a group named for a bucket team | Confirm the group naming convention with the data owners; one group per access tier is easier to audit than per-user grants |
| Scope and claim | Request the scope that carries group membership in the OIDC token, then map the group list to the claim MinIO reads | Exact claim name and scope are items to confirm against the authentik MinIO integrations guide and your MinIO version |
| Claim to policy name | Each group value becomes a MinIO policy name, for example a policy called readonly-finance matching a group of the same role | Policy names are case-sensitive and must match the MinIO policy object exactly; agree the naming pattern before the first user signs in |
| Policy content | Define bucket and action rights per policy (list, read, write) scoped to the named buckets or prefixes | Test each policy with a non-admin account; overly broad actions such as all-bucket write are a common error |
| Unmatched users | A user with no mapped group or an empty claim should receive no MinIO policy and therefore no bucket access | Verify with a test account that has no group; a default policy attached to all users would widen access silently |
| Keeping names identical | Store the group-to-policy list in version-controlled configuration and review it with every change on either side | Changing a group name in authentik without renaming the MinIO policy breaks access for that group at next sign-in |
| Admin access | Keep a separately managed MinIO root or admin path outside SSO for recovery | Community edition status affects long-term support; see the page on the edition and licensing question before you rely on this path |
Console access and API access need different checks
The browser console is the path most administrators see first. A user opens the MinIO console, is redirected to authentik, signs in, and returns to the console with a session. The authentik side needs an OpenID Connect provider with a redirect URI that matches the console address exactly, and the MinIO side needs the OIDC settings the authentik integration guide describes. The MinIO README lists an embedded web console as part of the product, so the console is the path most likely to exist in your chosen edition, but you should confirm that the console login flow and its OIDC settings behave the same way in the edition you deploy.
- Redirect URI match: Confirm the callback address registered in authentik equals the console URL users actually type, including scheme, host and port.
- Policy claim mapping: Sign in with users from each group and confirm the console shows only the permissions their mapped policy grants.
- Session end: Sign out in the console and confirm the session ends, then confirm a fresh attempt returns to authentik.
- Denied users: Sign in as a user with no mapped group and confirm access is refused rather than granted a default policy.
Test the console with a browser session on each user type, because a successful login does not prove the claims produced the right policy.
Scripts, CI jobs and the mc command-line client do not use the browser flow. They need credentials that MinIO accepts for S3 API calls. In an OIDC setup, the usual pattern is that the user authenticates with authentik, and MinIO issues temporary credentials tied to the token's claims. Whether your edition supports this exchange, and which command or workflow obtains the credentials, must be confirmed in the MinIO documentation for that edition before you design the team's process. Do not assume a static access key is the fallback without checking how it interacts with the SSO policy.
- Credential source: Document how a user obtains temporary credentials, which command or console action produces them, and how long they last.
- Claim propagation: Confirm the policy claim reaches MinIO on the credential exchange, not only on console login.
- Bucket scope: Test a read and a write against a bucket the user should reach and against one they should not.
- Automation identities: Decide whether CI jobs use SSO-derived credentials or separate service accounts, and test that path separately.
Record the exact mc version and the MinIO build used for each test, because the README says the community repositories are archived.
The MinIO README lists the mc command-line client and the embedded web console as components of the project. Both are tied to the MinIO server, but the mc repository is also archived, so the client you install may not receive updates. Treat the client version as a fixed input to your tests. The console and mc may obtain credentials through different mechanisms, which is why each needs its own result in your test record.
- Client version pinning: Record the
mcbuild used for testing and rebuild the test plan when the client changes. - Console versus CLI results: Log whether a user who can sign in to the console also gets working CLI access, and where the two differ.
- Configuration files: Check that alias configuration for SSO users does not store long-lived secrets in shared locations.
- Support path: Ask who supports a CLI issue in your edition, since the README describes community support as best effort.
Confirm with the vendor how each component obtains credentials in the edition you choose before writing runbooks for operators.
Because the two paths exercise different code and different claims, a single end-to-end login test does not cover both. The test plan should list each path, each user type and each permission boundary, with a pass or fail result recorded for every row. This matters most for regulated teams, who need evidence that access decisions were tested rather than assumed.
- Separate test cases: Keep console and API cases in different sections of the test plan with their own expected results.
- Revocation: Remove a user from the mapped group in authentik and confirm both console access and any issued temporary credentials stop working within the lifetime you documented.
- Failure modes: Stop authentik or cut the OIDC connection and confirm which paths fail and whether a break-glass administrator path exists.
- Evidence: Keep dated screenshots, command output and claim samples for the audit file.
The effort for this testing depends on your user groups and bucket layout, so scope it in writing with whoever will sign off the results.
Security settings that protect the MinIO sign-in path
Signing in to MinIO through authentik moves trust into two systems that must agree on redirect targets, claims and fallback access. The cards below are design decisions to settle with your security team before go-live, covering secret handling, redirect control, policy scope, recovery access, transport protection and sign-in auditing.
Client secret storage
The OpenID Connect client secret shared between authentik and MinIO lets MinIO exchange authorization codes, so it should never sit in shell history, plain environment files in version control or chat threads. Decide where the secret lives, such as a secrets manager or a Kubernetes secret with restricted read access, and who can rotate it. Confirm the rotation procedure and test that MinIO picks up the new value without a long outage.
Restricting redirect URIs
The redirect URI registered in authentik tells the provider where to send the user after login, so a broad or wildcard entry can let an attacker's endpoint receive authorization codes. Register the exact console and API callback addresses that your MinIO deployment uses, separately for each hostname. Review the list whenever a DNS name or ingress changes.
Least-privilege policies from claims
Mapping group claims to MinIO policies decides what each signed-in person can read, write or administer. Start from read-only or bucket-scoped policies and grant broader rights only to named groups. Keep the mapping in a reviewed file, and confirm that a user removed from a group in authentik loses the matching MinIO policy at their next sign-in.
Break-glass root path
If authentik is unavailable or misconfigured, administrators still need a way into MinIO. Keep a local root or admin credential stored offline under a documented custodian, and test it on a schedule. Limit its use to recovery, log each use, and rotate it after any event where it may have been exposed.
TLS on every hop
The browser, authentik, the MinIO console and the MinIO S3 API each exchange tokens or credentials, so each connection needs encryption. Use certificates that clients trust for the authentik issuer URL, the callback addresses and the object storage endpoint. Check that the issuer certificate chain is trusted by the MinIO host, since a missing intermediate is a common cause of failed sign-ins.
Sign-in event logging
Record successful and failed sign-ins in authentik and correlate them with MinIO access logs so that a single user's session can be traced end to end. Decide retention and who reviews the logs, and forward them to your central log platform if you run one. Confirm which events authentik exposes in your version before you write alerting rules against them.
Common MinIO and authentik SSO failures and fixes
This table pairs each common failure in an authentik to MinIO OpenID Connect login with its likely cause and the first fix to try. Work down the rows in order, since redirect and issuer problems block every other step, and confirm each value against the exact client settings in authentik and your MinIO configuration before changing anything else.
| Failure | Likely cause | First fix to try |
|---|---|---|
| Redirect URI mismatch | The redirect URI registered in the authentik provider does not match the callback URL MinIO sends, often because of a trailing slash, http versus https, or a different hostname for the console and the API. | Copy the callback URL from the MinIO configuration into the authentik provider's redirect URIs exactly, then retry from a fresh browser session. |
| Issuer or discovery URL errors | The configured OpenID Connect discovery URL points to the wrong application slug, or the issuer value in the discovery document differs from the URL MinIO uses to reach authentik. | Open the discovery document in a browser, confirm the issuer string, and set the MinIO OpenID configuration URL to that same issuer path. |
| Certificate trust between services | MinIO does not trust the certificate authority that signed the authentik endpoint, so it cannot fetch keys or the token endpoint. | Add the internal certificate authority to the trust store MinIO uses on its host or container, then restart MinIO and test the discovery URL from that host. |
| Users with no mapped policy receive access denied | The login succeeds, but the claim MinIO reads for policy names is empty or does not match any MinIO policy name, so the user has no permissions. | Create a MinIO policy with the exact name the claim carries, assign it to a test user in authentik, and check the token claims for that user. |
| Claim name mismatch | The claim name configured in MinIO, such as the policy claim, differs from the claim name authentik's scope mapping actually emits. | Inspect a decoded ID or access token from a test login, then align the MinIO claim setting with the claim name shown in the token. |
| Clock skew affecting token validation | The MinIO host and authentik server disagree on time, so tokens appear issued in the future or already expired during validation. | Confirm both hosts sync time with NTP, correct the drift, and retry the login before changing any SSO setting. |
Questions teams ask before connecting authentik to MinIO
What does an authentik and MinIO SSO integration cost, and what drives it?
The cost is the labor to configure and test the integration, so it depends on scope rather than on a license fee for the integration itself. The main drivers are the number of identity groups that must map to MinIO policies, how many distinct bucket access levels you need, whether the console and S3 API both require SSO, and the TLS and DNS work for the console and API hostnames. Recurring cost is mostly the platform you run: authentik, PostgreSQL, storage and certificate renewal. Ask any quote to itemize the claim design, policy mapping, TLS and DNS work, testing and handover. Note that the MinIO community edition status affects long-term cost, covered in the licensing question below.
Does the MinIO community edition still receive updates?
No, not in the way many teams assume. The minio/minio README says the repository is no longer maintained, the community edition is distributed as source only, and legacy binaries will not receive updates. The last tagged community release on GitHub is RELEASE.2025-10-15T17-29-55Z, published on October 16, 2025. The authentik MinIO guide itself warns that MinIO directs new deployments to AIStor. Before you build, confirm with MinIO which edition and support path you will run, because the OIDC configuration can be the easy part while the object storage platform underneath needs a maintained release.
Can authentik's Enterprise features be avoided for this integration?
Yes. The OpenID Connect configuration described in the authentik MinIO guide does not depend on Enterprise features. The authentik pricing page lists Enterprise-only items such as Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging. None of these is implied by the MinIO guide. Check your own requirements: if you need audit logging of sign-ins for a compliance program, confirm whether the open-source logs and your log forwarding meet that need before assuming Enterprise is required.
How long does a MinIO SSO integration take?
Duration depends on scope and on how many environments you must reach. A single-site test with one console, one group-to-policy mapping and a working hostname is a small job. Timelines extend with each additional group and policy, separate console and API access rules, production certificates and DNS changes, and the testing needed to prove both browser and CLI sign-in. Because DeployOpen works from a written scope, ask for a timeline tied to named deliverables and dependencies, such as the availability of your identity administrators and certificate authority. We do not quote a generic duration here.
What must our team provide before the integration starts?
Prepare three inputs. First, identity groups in authentik that match your access model, with membership confirmed by your identity administrators, because group claims drive MinIO policies. Second, a bucket layout that states which teams own which buckets and whether they need read, write or administrative access. Third, certificates and DNS: a trusted certificate for the MinIO console and API hostnames, the authentik issuer URL and the redirect URIs that will be registered. You should also name a break-glass path, such as a local administrator account, so a failed SSO change cannot lock out operators.
Can our internal team set up MinIO SSO without outside help?
Yes, if you have engineers comfortable with OpenID Connect, reverse proxies and object storage administration. The authentik MinIO guide walks through the provider configuration, so a capable team can follow it in a test environment. The harder parts are usually policy design, tuning claims for your groups, confirming TLS for both console and API, and writing the runbook for renewals and rollback. If your team lacks time or has no one who has run OIDC against object storage before, a fixed-scope engagement can cover those pieces. Either way, test sign-in for the console, the API and a CLI client before you move users.
What goes wrong most often with MinIO and authentik OIDC?
The most common problems are mismatched redirect URIs, a client secret that differs between the two systems, hostnames or certificates that the browser does not trust, and group claims that arrive empty or in an unexpected format. Users who sign in but receive no permissions usually have a claim-to-policy mapping gap rather than an authentication fault. Plan a test matrix that covers a user in each group, a user in no group and an expired certificate scenario. Keep logs from both authentik and MinIO during testing so you can see which claim reached MinIO and which policy it matched.
Does SSO for MinIO protect data on its own?
No. SSO controls who can sign in and which MinIO policies they receive, but the storage platform still needs encryption in transit, sensible bucket policies, backups and an upgrade plan. It also needs a supported release, which is the licensing and maintenance issue described above. Treat the SSO work as one control inside a broader design, and confirm the data protection and support model with your storage vendor or MinIO before you rely on it for regulated data.
How DeployOpen scopes the MinIO SSO work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and the MinIO SSO work is scoped the same way: as a fixed written scope agreed before any configuration starts. The scope is built in five steps. First comes the edition decision, because it determines what the OpenID Connect integration can rely on. The MinIO community repositories are archived, the community binaries no longer receive updates, and MinIO points new deployments to AIStor, so the scope must state whether the target is the community build, AIStor Free or AIStor Enterprise. Confirm that choice with MinIO and with your own licensing review before anything else is designed.
The second and third steps are claim and policy design, then configuration. The claim design defines which authentik group or attribute claims reach MinIO, how they map to MinIO policies, and who approves changes to that mapping. Configuration then covers the authentik OpenID Connect provider and application, the MinIO identity settings, and the console and API access paths. Each item in the scope names the authentik objects, the MinIO settings and the environments involved, so the written scope can be checked line by line at handover.
The fourth and fifth steps are testing and handover. Testing should cover a successful console login, an API call under each policy, a user who should be denied, and a documented fallback sign-in path for when authentik is unavailable. Handover delivers the configuration, the claim-to-policy map, runbooks and test evidence to your team. Ongoing support, upgrades and periodic access reviews can be taken on as a retainer after handover, which is usually the better fit when the platform changes often. Ask any partner, including DeployOpen, to state in the quote what is delivered, what your team must provide and what is excluded.
