How authentik signs users in to Box over SAML
Box single sign-on is configured with authentik acting as a SAML identity provider, and the Box account must be a Business or Enterprise plan. A Box Free or Personal account cannot use this setup, so confirm your plan level with Box before you build anything in authentik. Once the plan is confirmed, the work is a SAML provider and application in authentik, a matching SAML connection on the Box side, and a test sign-in from a non-admin account. The exact steps, field values and certificate handling follow the authentik Box integration guide, which should be treated as the source of truth for the configuration itself.
At a high level, a user opens Box or its sign-in page, Box redirects the browser to authentik, authentik authenticates the user against its own flows (including any MFA stage you have enforced), and authentik returns a signed SAML assertion to Box. Box then decides whether the user already exists. The important detail for planning is automatic user creation: when Box creates an account on first login from SSO, the assertion must carry an email address, a first name and a last name for that user. If any of those attributes is missing or mapped to the wrong field, the first sign-in fails or creates an account with incomplete identity data. Check that each authentik user who needs Box access has all three values populated, and decide whether those values come from manual entry, an upstream source or an enrollment flow.
Plan the attribute mapping before the first test. Confirm the SAML attribute names that Box expects against the integration guide, map them to the authentik user fields that hold email and name data, and run a test with a user created the same way your real users will be created. Also decide who holds Box admin rights, since that account should be tested separately from regular members. Ask your authentik and Box administrators to confirm three things in writing: the plan level on the Box side, the attribute names in the live configuration, and how leavers will be removed from Box if you are not using provisioning.
What you need before configuring Box SSO with authentik
Box SSO through authentik depends on three things lining up: the Box account tier, the authentik deployment and version you run, and the network and certificate path between users, Box and authentik. Confirm each area before you open either admin console, because a gap in one usually shows up later as a failed sign-in.
Box plan requirement
authentik's Box guide states that Box SSO requires a Business or Enterprise account. Confirm which tier your organization holds in the Box admin console before planning the work, because a Free or Personal account cannot be configured for SAML sign-in. If you are still choosing a plan, ask Box which tier includes the SSO controls you need and confirm the feature list on the current pricing page.
Minimum Box user count
All Box business plans require at least 3 users. Count the people who will sign in through authentik, plus any admins who must keep a non-SSO recovery path, and compare that with the seats you intend to buy. A small pilot group may not meet the minimum on a business plan, so confirm the seat count with Box before you schedule the configuration window.
authentik version and support window
authentik's security policy lists 2026.5.x and 2026.8.x as the supported versions receiving security fixes. Run one of those lines before you add a SAML provider for Box, and confirm the version on your running server rather than assuming it from the deployment date. authentik publishes security releases at least 24 hours in advance, so plan a window to apply them.
Single sign-on hostname and certificates
Box needs the authentik SAML endpoints to be reachable over HTTPS from users' browsers, with a certificate that browsers trust. Decide which hostname authentik will use for sign-in, confirm that the reverse proxy in front of it serves a valid certificate for that name, and plan how you will renew it. Copy the signing certificate and the metadata values from authentik exactly as they are issued into the Box configuration.
Network paths and firewall rules
Users need to reach both the authentik sign-in hostname and Box during sign-in, and the browser must be able to post the SAML response back to Box. Check any outbound proxy, egress filtering and DNS policies that apply to your users and to the authentik host. Document the paths you confirmed so that a failed login later can be traced to a network change rather than to the SAML configuration.
Attribute source for automatic user creation
Automatic user creation in Box needs an email address and a first and last name for each authentik user, so these fields must be populated before the first sign-in. Check how your users are created in authentik, whether from a directory source or by hand, and confirm that the given name and family name attributes are present on every account that will use Box. Missing names are the most common reason a first login fails to create a Box user.
Configuring the authentik SAML provider and Box SSO in order
This sequence takes you from a SAML provider in authentik to a verified Box sign-in path, with each step closed by a check so you know it works before SSO is enforced for everyone.
Confirm the Box plan and account owner
Before touching authentik, confirm with your Box administrator that the account is on a Business or Enterprise plan, since SSO depends on it. Confirm who holds the super admin role in Box and who will own the authentik application. Also confirm that every authentik user who needs Box access has an email address and a first and last name, because automatic user creation depends on those attributes. Done means you have written confirmation of the plan and a named owner for each side.
Create the SAML provider and application in authentik
In the authentik admin interface, create a SAML provider for Box and an application that uses it. Set the provider's audience, ACS URL and issuer values using the details in the authentik Box integration guide, and choose the signing certificate and the name ID mapping that match your Box setup. Confirm the mappings send the email address, first name and last name claims Box needs for user creation. Done means the provider saves without errors and the application appears in the authentik application list.
Export the metadata and certificate values
From the authentik provider page, copy the identity provider metadata or the individual values Box asks for: the SSO sign-in URL, the logout URL and the signing certificate. Store them in your change record and note which authentik provider they came from. Verify the certificate is the active signing certificate and has not expired. Done means you hold a complete set of values that you have checked against the provider page once, not copied from a previous test.
Enable SSO in the Box admin console
In the Box admin console, open the enterprise settings for single sign-on and enable SAML-based SSO. Paste the identity provider values from authentik into the matching fields. Keep SSO in a mode that does not yet force all users to sign in through it, so that existing administrator access stays available. Done means the Box settings page saves the configuration and shows SSO as configured but not yet enforced.
Set the sign-in and logout endpoints
Configure the sign-in endpoint and the logout endpoint in Box so they match the authentik application's URLs exactly, including the host name and path. A mismatch here is one of the most common causes of failed sign-in, so compare each value character by character. Confirm the logout behavior you want after a user leaves Box. Done means both endpoints match the values in authentik and you have recorded the logout behavior your team agreed to.
Assign the authentik application to a test user
In authentik, assign the Box application to a single non-administrator test account through a group or direct binding, and confirm the account has the email, first name and last name set. Then sign in to Box from a private browser session using that account. Check that Box creates the user if it does not exist, that the name and email are populated correctly and that the user lands in the expected Box group. Done means the test user signs in through authentik and their Box profile matches the source data.
Test with a non-admin account before enforcing SSO
Repeat the sign-in test with at least one more non-administrator account, including a user who is not yet in Box, to confirm automatic user creation behaves as expected. Test the logout path and confirm that a Box administrator can still sign in with a break-glass method that does not depend on authentik. Only after these checks pass should you enforce SSO for all users in the Box console. Done means each test is recorded with its result and a named person has approved enforcement.
How automatic user creation on first login behaves
Box can create a user account the first time someone completes a successful SSO sign-in from authentik, so administrators do not have to pre-provision every employee by hand. The condition is that the authentik user carries the attributes Box needs to build the account: an email address, a first name and a last name. The authentik integrations catalog states that automatic user creation needs all three for each user, so the first check is to confirm that the attribute mappings in the authentik SAML provider pass these values through, and that the users who will sign in actually have them populated in authentik.
If an authentik user is missing the email address, first name or last name, the sign-in should not be treated as a clean account creation. Audit the source of those values before go-live, especially for accounts created by a directory sync, an invitation flow or a manual import, where a blank field is easy to miss. Decide who owns the fix: the authentik administrator, the HR or directory team that feeds the attributes, or a named Box admin who will create the account manually. Test one account with an incomplete profile in a non-production Box tenant, and record exactly what Box shows the user, so support staff know what to expect.
Matching is the other half of the behavior. Box links an SSO sign-in to an existing Box user through the email address, so an authentik account whose email matches a Box user already in the enterprise will be linked to that account rather than creating a second one. Confirm in the Box admin console whether automatic account creation on first login is enabled for your enterprise, and confirm which email domains are verified and which users already exist, since mismatched emails are the most common cause of duplicate or unexpected accounts. Keep the email address in authentik as the single source of truth for each person, and document the check you ran so the result can be repeated after any change to the Box configuration.
Mapping authentik user attributes to Box account fields
This table compares each authentik user attribute that the Box SSO setup depends on with the Box account field it populates during automatic user creation. Read the Required column first, because a missing email, first name or last name blocks account creation, and then use the confirmation column to agree the exact attribute names and values with both administrators before testing.
| Field | Box account field it populates | Required for automatic creation | What to confirm with the Box admin and authentik administrator |
|---|---|---|---|
| Email address | Box login and primary identity for the user | Yes | Which authentik attribute carries the email, that it matches the verified Box domain, and that each user has one unique address |
| First name | Box user first name in the directory | Yes | That the authentik user record holds a first name for every person who will sign in, and how the name appears in Box profiles |
| Last name | Box user last name in the directory | Yes | That the authentik user record holds a last name for every person who will sign in, including single-name or non-Latin name cases |
| Group or role attribute used for access | Box group membership or admin role, if mapped by your team | No | Whether group membership is managed in Box after first login or pushed from authentik, and who owns that decision |
| Username or account identifier | Used by authentik to identify the user, not a Box login field in the basic setup | No | Whether the SAML NameID format sends email or another identifier, and that it stays stable when a user changes name |
| Account status (active or deactivated) | Whether the Box user can sign in | No | How leavers are disabled in authentik and whether Box deprovisioning is handled manually or by a separate process |
| Existing Box user with the same email | Matched to the existing account rather than creating a duplicate | Not applicable | Whether pre-existing Box accounts exist for these emails and how they were created, since mismatched records can cause sign-in problems |
Hardening the authentik to Box SAML trust
The trust between authentik and Box is only as strong as the settings on both sides. The cards below cover signing material, which users reach the application, how Box admins are forced through SSO without locking themselves out, session behavior and the authentik version you run. Work through them before go-live and again after each upgrade.
Signing certificate handling
The SAML provider in authentik signs assertions with a certificate and key that Box trusts through its metadata or certificate upload. Decide who can read and rotate that key, store it in your secret handling process rather than in a shared document, and record its expiry date. Before any rotation, plan a window in which you update the Box configuration and test a fresh sign-in, because a mismatch will block every user at once.
Scoping the application to groups
Bind the authentik application to a policy that admits only the groups meant to sign in to Box. Without that binding, any authentik user who can reach the application may be able to sign in, and automatic user creation will then add accounts you did not intend. Test with one account outside the target group to confirm it is refused.
Enforcing SSO for admins
Decide whether Box admins must sign in through authentik and whether any account keeps a password. Keep at least one break-glass administrator outside the SSO path, store its credentials under dual control, and test that it still works. Confirm with Box which enforcement settings your account plan exposes, since these depend on your subscription.
Session and logout behavior
Set authentik session lifetimes and decide whether a sign-out from Box should also end the authentik session. Shorter sessions reduce exposure on shared machines but add sign-in friction. Test the full cycle, including signing out of Box, signing out of authentik and returning to Box, and document the result so the help desk can explain it to users.
Keeping authentik supported
authentik publishes a security policy listing the versions that receive security fixes, and it announces security releases at least 24 hours in advance. Confirm that your running version appears on that list, subscribe to release notices, and plan upgrades as a scheduled change with a tested rollback. Re-check the Box trust after each upgrade, since a changed signing or metadata setting breaks sign-in.
Why Box SAML sign-in fails and how to fix it
This table lists the failures most often seen when users sign in to Box through authentik over SAML, with the likely cause and the first fix to try for each. Work down the rows in order, since a certificate or entity ID mismatch blocks sign-in before user creation or assignment is even reached.
| Failure | Likely cause | First fix to try |
|---|---|---|
| Certificate errors at sign-in | The signing certificate in the Box SSO configuration does not match the one authentik is currently signing with, often after a certificate was rotated or regenerated. | Export the current signing certificate from the authentik SAML provider and upload it again in Box, then retry a private browser session. |
| Entity ID or ACS URL mismatch | The Box entity ID or assertion consumer service URL was copied with a typo, a different region, or an old hostname from a test instance. | Compare the entity ID and ACS URL on both sides character by character and correct the one that differs, following the authentik Box guide. |
| Sign-in fails for new users only | Automatic user creation needs an email address and a first and last name on each authentik user, and at least one of these is empty. | Open the affected user in authentik, fill in the email, first name and last name fields, then have the user sign in again. |
| Email in the assertion does not match a Box account | An account already exists in Box under a different email address, or the authentik email differs in case or domain from the Box user. | Confirm the Box user's primary email matches the authentik email exactly, then update one side so they agree before retrying. |
| Access denied after successful authentication | The user is not assigned to the authentik application that carries the Box provider, so authentik refuses to issue the assertion. | Add the user, or a group the user belongs to, to the application's bindings in authentik and check the access policy result. |
| Account not on an eligible plan | Box SSO is only available on Business or Enterprise accounts, so SSO settings are unavailable or ignored on other plans. | Check the plan on the Box admin console before changing authentik settings, and ask your Box account contact to confirm the subscription tier. |
Questions buyers ask about authentik and Box SSO
Does Box SSO with authentik require a specific Box plan?
Yes. Box SSO requires a Business or Enterprise account, according to the authentik Box integration guide, so a Free or Personal account cannot use SAML sign-in through authentik. All Box business plans require at least 3 users and include unlimited storage. Before you buy or change a plan, confirm with Box which tier includes the SSO and user provisioning features your rollout needs, since features can differ between Business, Business Plus, Enterprise and Enterprise Plus. Also check that your domain and existing Box users are compatible with the account you choose.
What does an authentik and Box SSO project cost, and what drives it?
The cost has three parts: the Box subscription you already pay or buy, the authentik edition you run, and the labor to configure both sides. SAML SSO for Box is on the Business or Enterprise tier, and the authentik integration with Box is documented for SAML. Confirm whether your authentik use needs the Enterprise license, since the pricing page lists Enterprise features separately from the open-source edition. Labor cost rises with the number of identity sources, the state of your user data, the number of Box groups and policies you map, and whether you need a test tenant. Ask any partner for a fixed-scope quote that separates one-time setup from recurring support and upgrades.
How long does configuration take?
The duration depends mainly on identity data quality and how quickly your team can grant access. Automatic user creation requires an email address and a first and last name on every authentik user, so a directory with missing names or duplicate emails adds cleanup work before any SSO test begins. Other drivers include whether you have admin access to both the authentik instance and the Box admin console, whether a test tenant exists, and how many user groups must be mapped. Ask for a written timeline that lists the data cleanup, test sign-ins with a pilot group, and the enforcement date as separate milestones.
What does my team need to provide?
Your team needs to supply a running authentik instance or a plan to deploy one, administrator access to authentik and to the Box admin console, and a Box Business or Enterprise account. You also need a list of pilot users, a clean set of user records with email addresses, first names and last names, and a decision on which Box groups should map to authentik groups. Someone must own the Box domain verification and the decision to enforce SSO for everyone. Ask any provider to confirm these prerequisites in writing before work starts, so that access gaps do not appear in the middle of testing.
Can an internal admin set up authentik and Box SSO without a partner?
Yes, an experienced internal team can configure SAML between authentik and Box by following the integration guide, provided it has the right access on both sides and time for testing. The decision usually comes down to skills and risk tolerance. A mistake in attribute mapping or enforcement settings can lock users out of Box, so a team without SAML experience should test with a pilot group and keep a documented fallback. A partner is useful when you need a fixed-scope delivery, an independent review of the configuration, or help with the surrounding identity work. Compare the internal estimate with a written scope from a provider before deciding.
What changes for users after SSO is enforced?
After SSO is enforced, users sign in to Box through authentik instead of with a Box password, and their sign-in follows the authentication policies configured in authentik, such as multi-factor prompts. Existing Box users must have an email address that matches the identity authentik sends, otherwise they may land in a separate account. Users who already have a password-based Box login may need a clear cut-over message and a support path for locked accounts. Plan for shared links, mobile apps and integrations, and confirm with Box how each one behaves once SSO is enforced.
Does SAML SSO also handle deprovisioning of leavers?
Not automatically in every setup. Automatic user creation at first sign-in covers new users, but it does not by itself remove access when someone leaves. Removing a user in authentik stops new sign-ins, but existing Box sessions and content ownership still need an administrator's decision. Ask the provider how offboarding will be handled, whether through a manual process, an identity lifecycle tool, or a SCIM-based approach that your Box plan supports. Confirm the exact options with Box before you rely on any of them.
Where does the authentik and Box work fit with other identity projects?
The Box configuration is one application in a wider identity estate, so its design depends on how authentik is deployed, which upstream directories feed it, and which other SaaS apps share the same groups. If you plan to add several SaaS applications, define your attribute and group model once so each integration uses the same names. Operational questions such as backups, upgrades and monitoring of the authentik instance also affect how reliably Box sign-in works. Ask for a scope that states which of these shared layers the engagement covers and which remain with your team.
Testing Box SSO before you enforce it for everyone
Test Box sign-in with a small pilot group before you require SSO for the whole account. The point of the pilot is to prove three things in your own environment: a new authentik user can sign in to Box and be created automatically, the SAML response carries the name and email values Box needs, and an administrator can still reach the Box admin console if the SAML setup fails. Use dedicated test accounts in authentik, with a real email address and a first and last name on each, and sign in with each one from a clean browser session. Confirm that Box creates the user on first login and places the account in the expected enterprise. Then check the account's name and email fields in Box against what authentik holds. If a first name or last name is missing or wrong, fix the attribute mapping before you widen the pilot, because Box creates accounts from those values.
Next, inspect the SAML response itself rather than trusting the Box screen alone. Use your browser's SAML tracing tool or the authentik event log to view the assertion that authentik sends, and confirm that the NameID and the email, first name and last name attributes match the names your Box configuration expects. Check that the values for test users match exactly, including capitalization and any domain differences, since a mismatch can create a duplicate account instead of signing the existing user in. Confirm your recovery path before any enforcement step: keep at least one Box administrator who has a password-based or otherwise independent sign-in, and verify that this person can log in to the Box admin console with SSO disabled. Write down who holds that access and where the recovery steps are stored.
Only after the pilot passes should you require SSO for all users. Confirm the enforcement setting in the Box admin console, communicate the cutover date to users, and keep the pilot accounts in place to re-run the sign-in test after the change. Ask your team to confirm which Box plan your account is on, since SSO requires a Business or Enterprise account, and to confirm the authentik version they run against the supported releases listed in the authentik security policy. Plan a rollback owner and a window for it, and set the timeline from your own change process rather than from a generic estimate.
How DeployOpen scopes and delivers authentik and Box SSO
DeployOpen plans, implements and documents self-hosted authentik as the SAML identity provider for Box inside your own infrastructure. Engagements are fixed-scope, so the Box plan requirements, user attribute mapping and test accounts are agreed in writing before any configuration begins.
How we scope
- Confirm your Box account type is Business or Enterprise before any SAML work starts.
- Map which authentik users sign in to Box and confirm each has an email address, first name and last name.
- Agree in writing the authentik deployment, Box tenant, test users and cutover steps that the fixed scope covers.
How we build
- Configure the authentik SAML provider and application for Box, with attribute mappings for email and name fields.
- Test automatic user creation on first sign-in using a dedicated test account before any production users are switched.
- Verify sign-in, sign-out and failure paths against the agreed test cases, and record the results.
How we hand over
- Document the authentik and Box configuration, attribute mappings and the admin steps needed for future changes.
- Walk your administrators through first-login behavior, including how users are created and what they must have set.
- Provide a runbook for rotating SAML certificates and handling users who cannot sign in.
How we support
- Offer ongoing support, upgrades and continuous testing for authentik and the Box integration as a retainer.
- Review authentik security releases and the Box configuration when your scope calls for it under a retainer.
- Confirm with your Box account team any plan limits, such as user minimums, that affect your rollout.
