Invitation-only enrollment in authentik: when closed signup is the right default
If you need contractors, partners or customers inside your identity system but do not want anyone who finds your login page to create an account, invitation-only enrollment is the control to use. In authentik, the enrollment flow is what creates new users, and an invitation stage in that flow decides who can start it. Only someone holding a valid invitation gets past the entry point, so enrollment stops being a public form and becomes a controlled handoff from your team to the outside user. The invitation controls three things. First, who starts enrollment: the link is issued by an administrator or an authorized process, not by the open internet. Second, how long the link works and whether it can be used more than once, so a forwarded or leaked link has a limited window and a limited number of uses. Third, what the new account receives: invitations can carry prefilled attributes such as the organization, the sponsoring team or the group the user should join, so the account starts with the access its role needs rather than with a blank profile that someone must correct later. Binding the enrollment flow to policies adds another check, so that an invitation alone does not decide everything. Teams need this model when outside users must hold a durable identity but the population is not known in advance, or when the people who sponsor them are not identity administrators. Closed signup is usually the right default for regulated environments and for any system where an account grants access to data. Before you rely on it, confirm the invitation stage behavior, expiry handling and attribute prefill against the authentik documentation for the release you run, because these details have changed between versions and your test results should decide the rollout.
Invitation settings and policy bindings compared
This table compares the configuration choices that shape an invitation-based enrollment: link reuse, expiry, prefilled data, the access granted on completion, and policy binding. Read each row against the population you are onboarding, then confirm the exact setting names and behavior in the authentik release you run before you commit to a design.
| Choice | Fits when | Trade-off | Confirm in your release |
|---|---|---|---|
| Single-use link | Named contractors or individual customers where each person needs their own access record (illustrative: one invitation per consultant) | Every person needs a separate invitation, which means more administration but a clear audit trail per user | Whether a used invitation is consumed on first completion and how a failed attempt affects it |
| Reusable link | A partner cohort or training group that joins together and where individual invitations are impractical | Anyone who obtains the link can attempt enrollment, so the link must be paired with policy checks and short validity | Whether reuse is limited by count, by time, or only by the flow itself, and how usage is logged |
| Expiry window | Time-boxed onboarding, such as a project start date or a short contractor engagement | Short windows reduce exposure but create support requests when invitees miss the date | How expiry is enforced, what the invitee sees after expiry, and how to reissue an invitation |
| Prefilled attributes or fields | Invitee data is known in advance (for example, company name, role or customer account reference) | Prefilled values are only as trustworthy as the person who created the invitation, so review them before sending | Which user attributes or fields can be prefilled, and whether invitees can edit them during enrollment |
| Group or role on completion | Access must match the cohort from day one, such as a partner group that can reach only specific applications | Mistakes here grant access immediately, so the mapping should be reviewed with the application owners | Whether the group assignment happens in the enrollment flow or in a later stage, and how it is recorded |
| Policy binding on the enrollment flow | You need conditions such as allowed email domains, network location or invitation validity checked before an account is created | Each added policy adds a point of failure and support load, and a misconfigured binding can block all invitees | Binding order, the behavior when a policy denies, and whether bindings can carry an expiry date |
| Post-enrollment MFA or password stage | Contractors or customers must set a second factor or a strong password before reaching applications | Stages add friction for invitees, which affects completion rates and support volume | Which stages can follow the invitation stage and how they interact with the chosen password rules |
Setting up an invitation flow step by step
This sequence takes an authentik test deployment from a confirmed release to a working invitation link that creates a correctly grouped and attributed account, with a check at each stage. It is written so your team can verify each step before the flow reaches real contractors or partners.
Confirm the deployment and release in a test environment
Before building anything, confirm which authentik release your test instance runs and whether it is on a version that receives security fixes. Check the release line against the authentik security policy and the releases page, and note the deployment model (Docker Compose or Kubernetes) and the PostgreSQL instance behind it. Ask your team to confirm that stage names and fields in the admin interface match the documentation for that release, because enrollment screens have changed across versions. The step is done when you can log in as an administrator on the test instance and record the exact version in your change ticket.
Create the invitation stage and enrollment flow
In the admin interface, create an invitation stage and an enrollment flow that uses it, along with the user write and prompt stages that create the account. Keep the flow separate from any open enrollment flow so that the two cannot be confused. Name both objects clearly, for example with the partner or contractor program in the name, so that auditors and administrators can tell them apart later. The step is done when the flow appears in the flow list with the stages in the intended order and no stage is left unbound.
Configure link rules and prefilled attributes
Set the rules that govern each invitation link: whether it is single-use, when it expires, and which fields are prefilled from the invitation, such as the user's name, email address or an attribute that records their organization. Decide which fields the invitee may edit and which are locked, since a locked attribute is what downstream applications will trust. Confirm the exact options available for single-use and expiry on your release, because these settings are version-dependent. The step is done when you have created one test invitation with the attributes you intended and can see those values in the flow before submitting.
Bind the flow to policies that limit who can use it
Attach policies to the enrollment flow or its bindings so that only invitations created by authorized administrators are accepted, and so that the flow is unavailable outside the conditions you define. Choose the policy types based on your access model, such as group membership of the inviting administrators or the network context of the request. Document each policy and its owner, because a policy that is removed later reopens the flow. The step is done when a request that fails the policy condition is refused and a request that meets it reaches the enrollment screen.
Assign the target group in the flow
Add the stage or attribute mapping that places each new account in the target group for its population, such as contractors or partners, so that application access follows from group membership. Keep access grants on the group rather than on individual users so that offboarding is a single change. Confirm the group exists before the flow runs and that no default group grants broader access than the invitation intends. The step is done when a test enrollment produces an account whose group list matches the design document exactly.
Set the invitation flow as the link target
Point the invitation link at the new enrollment flow, and make sure no other flow or default setting redirects invitees to a general enrollment page. Review the brand or domain settings that the invitation page uses, because the default flow for a brand can override what the link opens. The step is done when following a freshly generated link lands on the intended flow and the screen shows the expected prompts.
Test single-use and expired links
Use one test invitation and try to complete enrollment twice. The second attempt should be refused, which confirms the link is single-use. Then create a second invitation with a short expiry configured on the test instance, wait until it lapses, and confirm that the link is refused. Record the outcome of each attempt and the time it was made. The step is done when both refusals are logged and reproducible, and when a valid link still completes enrollment.
Confirm the created account's groups and attributes
After a successful test enrollment, open the new account in the admin interface and check its groups, prefilled attributes and locked fields against the design. Confirm that an application configured for the target group sees the user and that a user outside the group does not. Remove the test accounts and invitations once the checks are recorded, and keep the test results with the change record for review. The step is done when every expected group and attribute matches, and any mismatch is traced to a flow, mapping or policy and fixed before go-live.
Invitation patterns for contractors, partners and customers
Contractors usually need access for one defined piece of work, so the invitation should carry the same boundary as the contract. Start from the engagement end date, then decide how long the invitation link stays valid. The link and the account are separate decisions. A short-lived invitation limits who can enroll, while group and policy assignments decide what the account can reach after enrollment.
- Short link lifetime: Set each invitation to expire soon after it is sent, so an unused link does not stay open in an inbox. Confirm the expiry options available in your authentik version.
- Named, single-use links: Issue one invitation per person and tie it to a name and an internal sponsor, so every enrollment traces back to one individual.
- Group assignment that matches the window: Add the contractor to a group created for that engagement, and bind applications to that group only.
- Sponsor and engagement attributes: Store the sponsor and engagement reference on the account so reviewers can answer who approved the access and why.
- Policy check on enrollment: Bind the enrollment flow to a policy that confirms the invitation is still valid before the account is created.
Test an expired link, a reused link and a valid link, and confirm that the valid enrollment reaches only the intended applications.
Partners often need many users from one organization, and the people involved may change over the life of the relationship. A reusable or cohort invitation can cover that need, but it widens who can enroll with a single link. Bind the invitation to a policy and a partner group so that the link admits only the intended cohort, and so that the group controls application access.
- One cohort per partner organization: Create a cohort invitation for each partner, not one shared link for all partners, so that revoking one partner does not affect the others.
- Policy binding on the enrollment flow: Use a policy to limit enrollment to the cohort, for example by checking attributes the invitation sets. Confirm which policy types your version supports for this check.
- Partner group with defined applications: Assign each cohort to a partner group and bind only the applications that partner needs.
- Usage limits and review: Decide how many enrollments a cohort link may accept, and review enrolled accounts on a schedule agreed with the partner.
- Removal path at the end of the partnership: Document who removes group membership and disables accounts when the agreement ends.
Confirm that a reusable link fails for someone outside the cohort and that removing a partner group takes effect for every account in it.
Customer invitations are usually sent at scale and carry identifiers that must match your billing or account records. The main design choices are whether each tenant or brand gets its own enrollment flow and how account identifiers arrive in the profile. Keep the identifier set by the invitation, not by the person enrolling, so customers cannot choose or change the value that links their login to their account.
- Per-tenant or per-brand flows: Give each customer group or brand its own enrollment flow when the wording, required fields or branding differ. Branding per domain is covered on its own page.
- Prefilled account identifiers: Set the customer account number or tenant ID as an attribute from the invitation so it does not depend on typing.
- Read-only identifiers: Make sure the identifier cannot be edited by the user after enrollment, and confirm that the attribute is not overwritten by the user profile form.
- Uniqueness and mapping: Decide how the identifier maps to your CRM or billing system and what happens if two records share the same value.
- Field minimization: Ask only for the information the enrollment needs, since each extra field becomes support and data-handling work.
Test that the prefilled identifier appears correctly for each tenant and that a customer cannot change it from the profile page.
An invitation expiry controls whether someone can still enroll. It does not control how long an enrolled account keeps its access. Contractors, partners and customers whose relationships end on a date need a separate mechanism for ending access, and that mechanism belongs to policy and group bindings rather than to the invitation. Plan the two controls together so that neither one is assumed to cover the other.
- Invitation expiry is not account expiry: An accepted invitation leaves the account in place, so the account still needs its own end date or removal step.
- Expired links do not remove existing access: Expiring or revoking a link stops new enrollments only.
- Binding expiry is a separate control: Time-limited bindings for policies, groups and users are covered in the temporary access topic, which explains how expired bindings behave.
- Offboarding steps: Write down who disables accounts, who removes group membership and how sponsors confirm the end of access.
- Audit trail: Keep records of invitation issue, use and expiry so reviewers can reconstruct who had access and when.
Confirm in a test environment that an account whose binding has expired loses the intended applications, and that an expired invitation cannot create a new account.
Keeping a forwarded invitation link from becoming open signup
The main failure mode is simple: an invitation link meant for one contractor, partner or customer gets forwarded to a colleague, pasted into a shared channel or indexed in a public place, and the person who opens it is treated as an invited user. Single-use and expiry limits reduce how long and how often a link works, but they do not decide who ends up with an account. What decides that is what the enrollment flow checks after the link is opened and what the new account is allowed to do once it exists. Treat the link as a bearer token that may be copied, and design the flow so a copy is worth little.
The controls that matter most sit inside the flow. Bind the invitation stage to the enrollment flow with a policy that checks the invitation context, such as whether the invitation is still valid, whether it was issued for this flow, and whether the address entered matches the address the invitation was created for. Prefilled attributes, such as the expected email domain or the partner organization, can be enforced by a policy rather than trusted as typed input. Group assignment should be the last step and should come from the invitation or from an explicit administrator decision, never from a default group that every enrolled user receives. Confirm in your version of authentik how each of these is expressed, because the names of stages, bindings and policy types change between releases.
Email delivery matters less than these policy and attribute choices. Whether the link arrives by a managed mail relay or by hand over a secure channel does not stop a forwarded link from working if the flow accepts any user who reaches it. Before go-live, test the flow as an attacker would: open the link from a second browser or device, use an address outside the expected domain, reuse the link after first use, let it expire, and try to enroll with a different username. Confirm that each attempt fails with the message you intend, that no account is created with privileges, and that the attempts appear in the audit and event logs. Record the results so the test can be repeated after upgrades.
Security risks in invitation enrollment and how to contain them
An invitation is a temporary grant of access made before the person is known to your identity system. The risks below share one root cause: the enrollment path creates accounts, groups and attributes ahead of verification, so each control has to bound what an invitation can do, how long it works and who can change it.
Leaked or forwarded links
An invitation link works for anyone who holds it, including a colleague who forwards it or a mail system that previews it. Limit each link to a single use and a short expiry window, and send it only to the address the invitee was approved for. Ask your team to confirm how the invitation stage enforces single use in the version you run, and test that a second use is refused. Treat any link sent to a shared mailbox as exposed.
Invitations that outlive the engagement
A contractor's invitation can remain valid long after the project it was issued for has ended. Set expiry on every invitation at issue time and record the engagement end date in your process. Review open invitations on a fixed schedule and revoke those with no matching engagement. Confirm how expired invitations behave in your release, since binding expiry behavior differs between policies, groups and users.
Over-privileged group assignment on enrollment
If the enrollment flow adds new users to a broad group, every invitation becomes a route to that group's applications. Create a dedicated group for each invitee type with the minimum application bindings, and set the group assignment in the flow rather than in a manual step. Ask an administrator to verify, in a test enrollment, which groups and application entitlements the new account actually receives.
Prefilled attributes users can alter
Attributes such as company, sponsor or account tier are often prefilled from the invitation so the user does not retype them. If the enrollment form lets the user edit those fields, the user can change the values that drive policy decisions. Mark prefilled attributes as read-only in the form where your version allows it, and keep authorization decisions tied to values set by administrators, not to free-text fields the user submits.
No audit trail for who invited whom
When an account is later questioned, you need to show who issued the invitation, when, to which address and what the account received. Confirm which events your edition records for invitation creation, use and account creation, and where they are forwarded. Audit logging is listed as an enterprise feature on the pricing page, so confirm the open-source edition's event coverage before relying on it, and keep your own record of invitations in your ticketing or HR system.
Enrollment flow editable by unauthorized staff
The invitation stage and its bound flow decide who gets in, so changes to them are changes to access. Limit flow and policy editing to a named group, require change review for enrollment flows, and export flow configuration so that unexpected edits are detectable. Confirm which administrator roles can edit flows in your edition and whether those changes appear in your audit records.
How much effort does invitation-only enrollment take?
What drives the effort of invitation-only enrollment in authentik?
The effort is driven by how many distinct audiences you onboard, how many enrollment flows each one needs, how complex the policies behind those flows are, and whether approvals or HR and ticketing systems feed the process. Each added audience usually adds a flow, a set of invitation rules, prefilled attributes and group or policy bindings to test. Approval steps and integrations with an HR system or ticketing tool add design work, error handling and a second system to verify. A single contractor flow with one approver is a small job. Five partner types with different access, expiry rules and approval paths is a much larger one.
Can a platform team set up invitation-only enrollment without outside help?
Yes, if the team already runs authentik in its own infrastructure and has someone who understands flows, stages and policies. The work is configuration rather than new code in most cases, so the main constraints are time and review capacity. Teams that have not yet built a flow, or that need to test it against real access rules for several audiences, often find an outside review useful. Confirm internally who will own invitation issuance, who will review policy changes and who will test expired and reused links before deciding how much to hand over.
What does the client need to provide before enrollment work starts?
The client should prepare a few concrete inputs so the scope can be written and the work can be tested:
Does invitation-only enrollment change the cost of open-source authentik compared with Enterprise?
The open-source edition is listed as free on the authentik pricing page, so software licensing is not the main difference in cost. Enterprise pricing is also listed there, at $5 per user per month billed annually plus $0.02 per external user per month, with Enterprise Plus starting at $20k annually. Enterprise adds features such as password history and enhanced audit logging, which some invitation designs may depend on. Check the feature list against your requirements before choosing an edition. DeployOpen does not set prices in this page. It quotes from a written scope that states the audiences, flows, integrations and testing to be covered.
How long does it take to build and test a first invitation flow?
The duration depends on the number of audiences, the approval path, the access rules and how many integrations are involved, so no fixed figure applies. A first flow typically includes building the invitation and enrollment stages, binding policies, prefilling attributes and testing expired, reused and revoked links. Testing takes as long as the access rules are complicated, and it should include a non-production instance. Ask for a timeline in the written scope, with named milestones for build, test and handover.
What should be tested before inviting external users to a live authentik instance?
Test each path an invitation can take, not only the happy path. For an engineer, that means checking that a single-use link cannot be reused, that an expired link is refused, that prefilled attributes land on the new account and that the policy bound to the flow rejects users who should not enroll. Confirm that a revoked or unused invitation behaves as your process expects, and that the audit trail records who was invited and when. Run these checks against a copy of your configuration in a test environment, and record the results so the security team can review them.
Who should approve the access rules behind each invitation?
The business owner of each audience should approve the access it receives, and the security or identity team should approve the policy logic that enforces it. Contractors, partners and customers often need different groups, lifetimes and applications, so one approval record per audience keeps decisions traceable. Agree on who can change these rules later, because invitation policies are often edited by people who did not design them. Name those owners in the written scope.
Limits to confirm before you design the invitation flow
Invitation-only enrollment depends on a few facts about your environment that no page can settle for you. Each card below is a confirmation to make with your own team, your vendor documentation or your network owners before you commit to a flow design. Together they decide whether the invitation flow can be built as documented and whether it can be operated safely.
Release in use and invitation behavior
Identify the exact authentik release running in your environment, then confirm in that version's documentation and release notes that the invitation stage, its link handling and its attribute prefill behave as you expect. Features move between releases, so a design written against one version may not match the next. Test the full path, from invitation creation through to the account being active, on a non-production instance running the same release before you rely on it.
Supported versions receiving security fixes
Check which versions the project currently supports with security fixes and whether your running release is on that list. Ask who in your team watches for security releases and how quickly you can apply one, since the project announces them at least 24 hours in advance. An enrollment flow that accepts unauthenticated visitors is part of your internet-facing attack surface, so an unpatched release is a direct exposure.
Email delivery for invitation links
Confirm how invitation links reach invitees in your deployment: which mail server sends them, whether the sender domain has valid SPF, DKIM and DMARC records, and whether your mail filters hold links from external senders. Test with the external domains your contractors and partners actually use. A link that lands in spam expires silently from the invitee's point of view, and administrators often mistake that for a flow fault.
Link delivery in air-gapped networks
If the deployment has no outbound mail, decide how invitation links travel: through a secure messaging channel your organization operates, an approved courier process, or a manual handoff by an administrator. Confirm that each channel is allowed by your data handling rules and that the link cannot be forwarded or logged in a place that outlives the invitation. Document who may create invitations in this mode, because the administrator becomes the delivery path.
Edition and feature set
Confirm which edition you are licensed for and whether the features your design needs are included in it. The project's pricing page separates the Open Source edition from Enterprise and Enterprise Plus, and lists audit logging and some other controls only in the paid tiers. Also confirm that the license terms for the code you run match your own use, since the enterprise directory is under a separate license. Ask in writing which features your invitation design depends on.
Interaction with recovery and MFA setup
Map how an invited user moves from enrollment into password setup, MFA enrollment and any recovery path, and confirm that each step runs in the order you intend. An invitee who has not yet enrolled a second factor may hit a recovery or MFA stage that expects one, which can lock them out before they start. Test each combination of invitation, password policy and MFA requirement with a sample account, and check that recovery cannot be used to bypass the invitation's expiry or single-use rules.
How DeployOpen scopes and delivers invitation enrollment
DeployOpen treats invitation-only enrollment as a set of flows, stages and policies that must be agreed in writing before anyone edits the authentik configuration. We plan the invitation path, build it in your own infrastructure, test it against the people and applications it affects, and hand over the configuration with documentation your team can maintain.
How we scope
- We confirm who gets invited, which groups and applications they reach, and how long invitations should stay valid.
- We record the enrollment flow, the invitation stage, prefilled attributes and the policies that gate each step in the written scope.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
How we build
- We configure single-use, expiring invitations and bind the enrollment flow to policies that match your partner and customer rules.
- We test each path with sample invitees, including expired, reused and out-of-scope invitations, and record the results.
- We confirm your authentik version and check the upgrade notes for any flow or stage changes that affect invitations.
How we hand over
- You receive exported flow and policy configuration, a runbook for issuing and revoking invitations, and a test record.
- We document which admin roles may create invitations and how to review who joined through each invitation.
- Your team walks through the handover so administrators can issue invitations without help from us.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover re-testing invitation flows after each authentik security or feature release you adopt.
- Ask any partner to confirm response times and coverage in the written quote, since these vary by agreement.
