Two different questions get called access control. First: who is allowed to become a user. Second: what that user may do after sign-in. Authdog answers them in different places. Mixing them up is how a public sign-up form ends up granting admin.
Who can create an account
Open Authentication > Restrictions for the environment.
Sign-up mode is one of three:
| Mode | Who gets an account |
|---|---|
| Public | Anyone who completes sign-up. |
| Restricted | Nobody through the sign-up form. Access is invite, a user you create, or enterprise SSO. |
| Waitlist | People can join, and you approve them before they have an account. See Set up a waitlist. |
Enable user registration on Users > Settings is a separate switch. Off means only existing users can sign in, even if the mode is Public.
Require signup for first login stops a first Google (or other OAuth) sign-in from creating the user by itself. The browser lands on the hosted signup page instead. Leave registration on when you use that switch. The full sequence is in Users.
Which emails qualify
On the same Restrictions tab:
- Allowlist: only these domains may sign in. This is the right default when the app is for one customer's employees. Add the domains before you enable it. An allowlist with no domains cannot be saved.
- Blocklist: these domains may not sign in.
- Block email subaddresses:
+,=, and#aliases are allowed once per base address. After[email protected]is used,[email protected]is rejected for sign-up and for adding to an existing account. - Block sign-ups that use disposable email addresses: known throwaway domains are rejected.
The same email rules are enforced on email/password registration and on waitlist join. Test an address you expect to fail before you announce the restriction. A typo in an allowlist locks out the customer you meant to admit.
Enterprise SSO does not replace the allowlist. Domain routing on the connection picks the identity provider. The allowlist still decides whether that email's domain is welcome. See Enterprise SSO.
What a signed-in user can do
A session is not a permission. After the identity check, the environment uses exactly one authorization model:
- RBAC when seats and roles match the product.
- ABAC when the rule is attributes, written in Rego and evaluated at the edge.
- FGA when access is a relationship on a specific object.
Pick one and stay with it. Authorization compares them. Changing the model later rewrites every check in your app.
Invitations (expiry defaults to 7 days, under Authentication > Features) are how a restricted environment still grows. They do not bypass authorization. An invited user still needs a role, a policy, or a relationship before a protected API should succeed.
Related
| Read | To learn how to |
|---|---|
| Authorization | Choose RBAC, ABAC, or FGA |
| Set up a waitlist | Approve accounts instead of opening sign-up |
| Users | Registration switches and the waitlist queue |
| Authentication | Restrictions, methods, and features |