That’s correct. Your setting for the GRIST_FORCE_LOGIN flag is already the default.
Broadly, your OIDC setup handles authentication, meaning it will work with users to verify their identity, and then vouch for that to Grist. Within Grist, you can control authorization, meaning: what does the user have the right to do. That’s where the team site sharing setup is useful:
In the team site sharing setup, it is possible to authorize a user that your OIDC setup would not allow through. In that case, your OIDC setup takes precedence, since the user will just never reach Grist.
It is also perfectly normal to have someone that your OIDC setup recognizes and authenticates, but they are not actually authorized to access a team site.
By default, users do not have access to team sites until it is specifically authorized (or some material on the site is shared in a public and list-able way). There are some reasonable feature requests around this. ANCT contributed a bulk-add-user UI to speed things up for themselves.
If GRIST_SINGLE_ORG is set, then no, that flag constrains Grist to have a single team site, so personal sites simply cannot be reached I believe.
Coming back to the relationship between orgs, team sites, workspaces, and users in the self-hosted version:
- Orgs is an old synonym for team sites that survives in environment variable names and source code.
- Workspaces are like non-nestable folders. They contain documents, and each workspace is in a team site.
- For users, I’m hoping the sketch of the separation of authentication and authorization responsibilities above helps a bit. User authorization operates at the site, workspace, and doc level - each have a “Manage Users” option. There is default inheritance of authorization by nested resources such as docs within workspaces within team sites. This can be overridden.
There’s not much that is special to say about authorization, the support documentation should hold for self-hosted in large part, apart from stray references to SaaS limits.