Authentication, roles and per-record ownership

B1 was "can different people see different things", and it is the question clients ask first. The answer has three layers that people routinely confuse, so this chapter separates them before showing what is generated.

Three questions, not one

• Authentication
• Who are you? Produces an identity, or a 401
• Authorization
• May people like you do this? Roles and permissions, or a 403
• Ownership
• May you do it to this record? Per-row, or a 404

Most teams build the first, assume the second is the whole of the problem, and discover the third when a salesperson can open another salesperson's accounts by changing a number in the URL.

What arrives

A new project already has: registration, login, logout, password reset, email verification, refresh tokens, server-side sessions, account lockout, optional two-factor, and OAuth and SAML behind flags. Three roles exist by default,ADMIN, EDITOR and USER, and you can add more.

None of this is a plugin you enable. B2's answer is present before you write a line, for the reason chapter twenty seven gave: an opt-in security feature is a security feature most projects do not have.

Sessions, not just tokens

A JWT alone cannot be revoked: it is valid until it expires, so "log this device out" is not expressible. Every refresh token here is backed by asessions row, stored as a SHA-256 hash rather than the token itself.

That buys four things a bare JWT cannot:

• revoke one device, from the account page
• detect replay: a refresh token used twice means it was stolen, and the whole session chain is killed
• idle and absolute timeouts
• a password change signs out every device

Four layers on the sign-in form

The login endpoint is the most attacked route in any application, and it carries four defences:

• 1
• A rate limit on the route
• 2
• A lockout on the account after repeated failures
• 3
• A growing delay on repeated failure
• 4
• A locked account answers exactly like a wrong password

The fourth is the one that gets missed, and it is the interesting one.

If a locked account says "this account is locked" and an unknown one says "no such user", you have built an oracle for discovering who has an account. Combined with a breach list, that is a targeted attack. The polite, helpful error message is the vulnerability.

Roles, and adding your own

grit add role MODERATOR

That updates seven places: the Go constants, the Zod schema, the TypeScript union, the sidebar visibility, the form options and the seeded permissions. Doing it by hand means finding all seven, and the one you miss is usually the frontend, where the role exists but nothing shows for it.

Protecting a route:

admin := api.Group("/admin")
admin.Use(middleware.RequireRole("ADMIN", "EDITOR"))

And in a service, where it also holds for jobs and imports:

if !authz.Can(ctx, "invoices.delete") {
    return respond.ErrForbidden
}

Ownership is the one that bites

Roles say "editors may delete invoices". Ownership says "this editor may deletethis invoice".

grit generate resource Invoice --owned-by user \
  --fields "number:string, total:money"

That adds a UserID column and, more importantly, scopes every generated query by the actor in the context. Listing returns only yours. Fetching someone else's returns 404, not 403, for the reason chapter thirty three gave.

The scoping lives in the service rather than the handler, so it applies to the CSV import, the export, the background job and the CLI, which is the whole argument of chapter thirty two meeting the problem it was written for.

Multitenancy is the same idea one level up

B9 asked "can two of our clients use one system". Ownership scopes to a user; multitenancy scopes to an organisation, through the same context.

The property to hold onto: *isolation is not a feature you add, it is something every query must have*. One forgotten WHERE in one place, in a background job or an export rather than a route, and one client sees another's data.

That is why it travels in the context rather than being a parameter each method remembers to apply. A parameter can be forgotten at one call site. A context that carries the organisation is applied by the layer that builds the query.

What is not solved for you

Two honest limits.

Permission design is yours. The framework gives roles, permissions and per-record ownership. Deciding that a regional manager sees their region, and what happens when someone moves region, is domain modelling and nothing generates it.

Approval workflows are not authorization. "An invoice over ten thousand needs a second approver" is a business rule that lives in a service, possibly a saga. It looks like permissions and it is not, and modelling it as a role produces a mess.

grit new tenancy-lab --api
cd tenancy-lab
grit generate resource Note --owned-by user \
  --fields "title:string, body:text"
grit migrate
grit start

curl -s -H "Authorization: Bearer $GRACE" \
  localhost:8080/api/v1/notes/1 | jq

Assignment

Commit your work with the message Auth - Assignment One, exactly as written, so the leaderboard can score it.