Put a self-hosted 3D print library behind SSO

If you already run Authentik, Authelia, or another OpenID Connect provider, PrintStash can sit behind it. Members sign in with the account they use for everything else, PrintStash creates their user on first login, and membership of one group you nominate decides whether they land as an administrator.

The thing to understand before you plan a rollout: the group mapping is one bit, administrator or not. Everything more granular, which collections someone can edit and which printers they can start jobs on, is assigned inside PrintStash and does not come from the identity provider. SSO solves who gets in, not who can do what.

What you configure

The settings live under Settings, SSO, and the client secret is stored encrypted rather than in plain text.

You need the issuer URL, a client ID, and a client secret from your provider, plus a redirect URI pointing back at your PrintStash. The rest has defaults you should check before rollout: the requested scopes are openid profile email groups, the username comes from the preferred_username claim, groups come from a groups claim, and the group that grants administrator is printstash-admins until you change it. The sign-in button’s label is configurable too, which is worth setting to whatever your members call the identity provider.

The login flow itself is the standard one, done properly: authorization code with PKCE, the provider’s discovery document read for endpoints and keys, the ID token’s signature validated against the published JWKS, and both state and nonce checked before anything is provisioned.

There is also a flag for allowing an insecure HTTP issuer, which exists for local testing. Leave it off.

What happens on first login

A member who has never signed in gets a user created on the spot, with their username taken from the claim and made unique if it collides with someone already there, and their email copied from the token. The account is keyed on the issuer plus the subject rather than on the username, so someone renaming themselves in your directory does not become a second user.

Their password hash is deliberately unusable, so an SSO-provisioned account cannot fall back to a local password. Local logins keep working for accounts that have one, which matters more than it sounds: it is the way back in when the identity provider is unavailable.

Administrator status is recomputed on every login from the current group membership. Remove someone from the admin group in the directory and their next sign-in demotes them, without anyone touching PrintStash. An account deactivated inside PrintStash is refused at login even if the directory still considers it valid, so local deactivation is the hard stop.

What SSO does not do for you

Three things stay manual, and a rollout plan that assumes otherwise will disappoint people.

Collection access is granted in PrintStash at view, edit, or admin, per collection. There is no mapping from a directory group to a collection role, so a new member arrives able to sign in and sees only what your default collection layout gives them.

Printer access is the same. Since v0.11.1, view, print, control, and admin are granted per printer, and printing also requires edit access to the source model’s collection. That combination is genuinely useful in a shared lab, since you can let a class watch every machine while only staff start jobs, but it is assigned per person inside the app. The makerspace shared access guide puts SSO in context as one piece of the whole access-control job alongside member logins, collection roles, per-printer permissions, and the audit trail.

Deprovisioning is partial. Removing someone from your directory stops them signing in, and it does not remove their PrintStash account, their uploads, or their API keys. If someone leaves, deactivate the account in PrintStash as well, which also revokes the keys that inherit from it.

Whether it is worth it for your space

For a makerspace with a handful of staff and no existing identity provider, honestly, no. Standing up Authentik to avoid creating eight accounts is a lot of infrastructure for a small problem, and the makerspace library setup covers doing it with local accounts, collection roles, and per-user API keys.

It earns its place when the directory already exists and is the system of record: a university lab where students arrive and leave every term, a company where offboarding runs through one place, or anywhere the alternative is a shared login on a sticky note. Then the win is not convenience, it is that access ends when employment or enrolment ends, without anyone remembering to do it here.

The audit log is what makes that verifiable after the fact. It records who changed what, and since v0.11.4 cookie-authenticated mutations retain their actor properly, so an action taken through the browser is attributable to the person who took it rather than landing anonymously.

Questions that come up

Which identity providers work with it?

The implementation is generic OpenID Connect built on the provider’s discovery document, and the project names Authentik and Authelia as the providers it targets. Anything that publishes a standard discovery endpoint, supports authorization code with PKCE, and can put group membership into a claim is the same shape of setup, though for anything outside those two I would test before promising it to members. What you need from any of them is the same short list: issuer URL, client ID, client secret, redirect URI, and a claim carrying groups.

Can I map directory groups to collection or printer permissions?

No. Group membership decides one thing, whether the user is an administrator, by intersecting their groups with the admin group list you configure. Collection roles and per-printer grants are assigned inside PrintStash per user. For a lab this usually means a short onboarding step after someone’s first login. Design the collection tree so that the state a new member lands in is already close to right for most people, and that step stays short.

What happens when the identity provider goes down?

SSO logins stop, because PrintStash has to reach the discovery endpoint and validate a token against the provider’s keys. Local login stays available, which is why keeping at least one local administrator account with a strong password is the precaution that matters here. Sessions already issued are normal PrintStash sessions and are not revalidated against the provider on every request, so people already signed in are not thrown out the moment the provider blinks.

Does someone removed from the directory lose access immediately?

They lose the ability to sign in again, not their existing session or their data. Administrator status is recomputed at each login, so a demotion takes effect on the next sign-in, but an active session continues until it expires. For a real offboarding, deactivate the account inside PrintStash too: that refuses the login outright, invalidates sessions, and covers the API keys the account owns, which would otherwise keep working from a script on a workstation.

Is SSO required to share a library with several people?

Not at all, and most installations should not bother. Individual accounts with collection-level roles give you attribution, revocation, and per-user API keys without any external dependency, and expiring share links cover visitors who should never have an account. SSO is worth adding when you already run an identity provider and want PrintStash’s access to end with it.

Sources

• PrintStash backend/app/services/oidc.py, backend/app/core/config.py, and the SSO settings card in the repository for the PKCE flow, the claim and group defaults, just-in-time provisioning, and how administrator status is recomputed. Checked August 19, 2026.
• The v0.11.0 release notes for the OIDC feature, v0.11.1 for per-printer access control, and v0.11.4 for audit-log actor retention on cookie-authenticated mutations.