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](/docs/secure/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](/docs/console/users#require-signup-for-first-login).

## 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 `ada+one@example.com` is used, `ada+two@example.com` 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](/docs/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](/docs/concepts/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](/docs/concepts/authorization) | Choose RBAC, ABAC, or FGA |
| [Set up a waitlist](/docs/secure/waitlist) | Approve accounts instead of opening sign-up |
| [Users](/docs/console/users) | Registration switches and the waitlist queue |
| [Authentication](/docs/console/authentication) | Restrictions, methods, and features |