Planning Authorization Rules in Amplify Gen 2 Data

I plan authorization before I build an admin screen. A data model can look harmless in TypeScript while one broad rule gives a browser more access than the interface shows. My starting document lists each actor, each operation, and the fields that actor may receive. That table becomes the basis for the schema and the test plan.

The Amplify authorization documentation describes public, guest, authenticated, owner, group, and custom strategies. Amplify combines multiple rules with logical OR, and field-level rules replace the model-level rules for that field. Those two details affect almost every review I perform.

Write the access table before the schema

I use rows for anonymous visitors, signed-in customers, editors, administrators, and backend jobs. The columns are create, read, update, and delete. I add a separate column for sensitive fields because record access and field access are different decisions. A public article may expose its title and body while keeping internal notes out of every public response.

The table forces vague statements such as "users can manage content" into testable permissions. It also reveals where a single model contains data with two security levels. In that case I either add field authorization or split the private data into another model.

Choose the narrowest matching rule

Public API-key access suits content that anyone may read. Guest IAM access can cover anonymous application users when the project needs Cognito identity-pool controls. allow.authenticated() applies to every signed-in user, so I do not use it as a substitute for administrator access. Owner rules fit records controlled by one identity, while static groups fit roles such as Admin or Editor.

I write the operations on each rule. A public rule that needs read access gets .to(["read"]). Leaving the operation list broad can turn a publishing API into a public write API.

Treat field rules as a separate policy

Amplify applies the most specific rule available. A field with its own authorization does not inherit the model rule. I review each protected field as though it were a small model: who can create it, who can read it, and who may change it later?

Owner fields deserve extra attention. Amplify can populate ownership for a new record, but an owner may be able to reassign the owner value unless the field rule prevents that change. I test reassignment instead of assuming the generated owner behavior matches the business rule.

Test with the identity that will make the request

A successful admin request proves little about the public client. I run the same read or mutation with the intended authMode: API key or identity pool for anonymous access, user pool for signed-in access, and IAM or a resource grant for backend work. I also test the expected denial.

My minimum matrix covers anonymous read, anonymous write, ordinary signed-in read, cross-owner update, admin update, and a request for protected fields. I keep the error response with the test evidence because a blank interface can hide an authorization failure.

Avoid broad access for internal tools

An admin interface should not force the public model to accept public writes. I grant an administrator group the required operations or route privileged work through a server function with an explicit resource grant. The browser still receives only the permissions carried by its identity.

Machine-to-machine work needs the same boundary. I name the function, the models it can access, and the operations it performs. A general IAM policy may be faster during development, but it makes later review harder and increases the effect of a compromised function.

Run a release review

Before deployment I inspect the schema diff, deploy to an isolated environment, and rerun the identity matrix against real AppSync behavior. I query fields the UI does not display, try mutations from the wrong owner, and confirm logs do not contain tokens or private records.

• Every model has an explicit production rule.
• Public rules list allowed operations.
• Protected fields have their own tests.
• Backend resources use scoped grants.
• Denials are expected and visible in monitoring.

Need help with Amplify?

If your Amplify schema has grown faster than its access policy, Terry Hunt Dev can review the data model through its AWS development service. Bring the actor list and the operations each actor needs to a technical consultation.