Outline OIDC Groups
To set up outline oidc groups, link your identity provider and map group claims. The wiki reads these claims at login to place users into matching workspaces. Many teams start by linking their main single sign-on provider to the wiki app. They pass group names in the login token so teams get shared folders. When roles are too broad, users can read or edit pages they do not need. A single broad group claim can expose sensitive internal docs to the whole company. How outline oidc groups work at
K8s OIDC Authentication: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To set up outline oidc groups, link your identity provider and map group claims. The wiki reads these claims at login to place users into matching workspaces. Many teams start by linking their main single sign-on provider to the wiki app. They pass group names in the login token so teams get shared folders. When roles are too broad, users can read or edit pages they do not need. A single broad group claim can expose sensitive internal docs to the whole company.
How outline oidc groups work at login
OpenID Connect lets your identity provider check who a user is at login. The provider sends a signed token back to the wiki app after login. That token holds basic user facts like an email and a display name. It can also carry a list of group names from your central directory.
The wiki app reads this token each time a person signs in. If the app supports group syncing, it matches token groups to local workspace groups. Users join the right collections without an admin adding them by hand. When a person leaves a team in the directory, the next login updates them.
Many self-hosted wiki editions handle basic login well but treat group claims with limits. In some editions, the login token only proves identity and creates a base account. Admins still have to assign workspace groups inside the app or use directory sync. Teams must check whether their wiki edition maps token claims or needs directory sync.
What native group mapping solves and what it misses
Central group mapping cuts down on manual user work for your support admins. New hires get the right wiki spaces on day one through their directory profile. When someone changes roles, you update one central directory instead of ten separate tools. This keeps basic workspace entry tied to your main company directory.
Still, login group mapping only controls who enters the app at the front door. Once a user logs in, their standing role stays active for the whole session. The login check cannot see what pages, databases, or servers they touch next. Teams often store database queries, server steps, and support guides inside these wiki pages.
K8s OIDC Authentication: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
An engineer reads a wiki guide and runs those commands against live production systems. Native wiki groups cannot check or limit the commands an engineer runs after reading. They also cannot mask sensitive fields like emails, phone numbers, or card numbers in results. Login groups decide who reads the docs, not what happens on live targets.
Keeping wiki roles and live system work safe
To keep systems safe, separate wiki reading roles from live production system permissions. Give teams small, clear groups in your identity provider for each doc collection. Do not map a single company-wide group to spaces that hold sensitive operational details. Review your identity provider claims often to make sure old groups do not linger.
Treat the wiki as a place for guides, never as a vault for secrets. Never put raw database passwords, API keys, or national IDs inside shared wiki pages. Even with tight group claims, a shared page is easy to copy or export. Pair your clean wiki group setup with strict controls on your actual backend systems.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does the wiki sync OIDC group claims on every login?
The app checks the login token each time a user starts a new session. Whether it updates local groups depends on your edition and directory sync settings.
Why are my users not joining groups after signing in?
Your identity provider might not include the group list inside the login token. Check that your provider sends the claim and that group names match your workspace.
Should we store database credentials in restricted wiki groups?
No, you should never store passwords or keys inside wiki pages, even restricted ones. Keep secrets out of docs and control database sessions directly at the target level.