<p>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.</p><p>The <a href="https://docs.amplify.aws/react/build-a-backend/data/customize-authz/">Amplify authorization documentation</a> 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.</p>

<h2>Write the access table before the schema</h2>

<p>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.</p><p>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.</p>

<h2>Choose the narrowest matching rule</h2>

<p>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. <code>allow.authenticated()</code> 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.</p><p>I write the operations on each rule. A public rule that needs read access gets <code>.to(["read"])</code>. Leaving the operation list broad can turn a publishing API into a public write API.</p>

<h2>Treat field rules as a separate policy</h2>

<p>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?</p><p>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.</p>

<h2>Test with the identity that will make the request</h2>

<p>A successful admin request proves little about the public client. I run the same read or mutation with the intended <code>authMode</code>: 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.</p><p>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.</p>

<h2>Avoid broad access for internal tools</h2>

<p>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.</p><p>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.</p>

<h2>Run a release review</h2>

<p>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.</p><ul><li>Every model has an explicit production rule.</li><li>Public rules list allowed operations.</li><li>Protected fields have their own tests.</li><li>Backend resources use scoped grants.</li><li>Denials are expected and visible in monitoring.</li></ul>

<h2>Need help with Amplify?</h2>

<p>If your Amplify schema has grown faster than its access policy, Terry Hunt Dev can review the data model through its <a href="/services/aws-development">AWS development service</a>. Bring the actor list and the operations each actor needs to a <a href="/contact">technical consultation</a>.</p>

Plan Amplify Gen 2 authorization rules for public reads, owners, groups, administrators, and server-side access without exposing private fields.

Planning Authorization Rules in Amplify Gen 2 Data

Plan public, signed-in, owner, group, and server access before an Amplify Gen 2 data model reaches production.

<p>When an Amplify application fails only on localhost, I identify the backend before changing frontend code. The <code>amplify_outputs.json</code> file contains the endpoints and identity configuration the client uses. An old file can send a healthy interface to a deleted sandbox, another region, or a user pool where the current session has no meaning.</p><p>I debug the connection in layers: file origin, endpoint reachability, authentication, requested operation, and cache. That order prevents a 401 from turning into unrelated component changes.</p>

<h2>Identify who generated the file</h2>

<p>I inspect the file's data endpoint, region, and auth configuration, then compare them with the active sandbox or hosted branch. I record the command used to generate it. A file copied from a teammate or downloaded for staging should not be treated as local-sandbox configuration.</p><p>Generated configuration is not a secret store, but it still belongs to a known environment. I follow the repository's tracking policy and avoid swapping files without documenting the target.</p>

<h2>Check the endpoint outside the page</h2>

<p>A DNS failure, TLS failure, and GraphQL authorization response point to different layers. I confirm the hostname resolves and the API responds before looking at React state. Browser developer tools show the request URL and status; a small server-side request can remove browser caching from the test.</p><p>If the endpoint no longer exists, I regenerate outputs for the active sandbox or branch rather than editing the JSON by hand.</p>

<h2>Match the auth mode to the schema</h2>

<p>A public query may use an API key or guest IAM mode, while an admin mutation may require the Cognito user pool. The schema rule and client <code>authMode</code> must agree. I compare the failing operation with the <a href="https://docs.amplify.aws/react/build-a-backend/data/customize-authz/">Amplify authorization documentation</a> and test the same call with a known identity.</p><p>A successful public list does not prove an authenticated mutation will work. I test each path on its own.</p>

<h2>Refresh expired or foreign sessions</h2>

<p>Local storage can retain tokens from a user pool associated with an older outputs file. I sign out, clear only the application's auth state, and sign in through the current pool. I avoid deleting all browser data before capturing the failing request because that erases useful evidence.</p><p>If the token is present, I check its issuer and expiration without publishing the token. A token from another pool should be discarded, not copied into a request header.</p>

<h2>Regenerate instead of patching</h2>

<p>For a deployed branch, Amplify documents <code>npx ampx generate outputs --app-id ... --branch ...</code>. For a sandbox, I let the sandbox workflow create the matching file. Manual endpoint edits hide the source of truth and are lost on the next generation.</p><p>I restart the development server after replacing configuration and confirm the browser loaded the new endpoint. Next.js can retain environment and module state across refreshes.</p>

<h2>Keep a short diagnostic record</h2>

<p>I save the error category, sanitized endpoint host, expected environment, generation command, and successful verification. That record helps when the same symptom returns after a branch switch.</p><ul><li>Confirm file origin.</li><li>Test endpoint reachability.</li><li>Match auth mode and schema.</li><li>Refresh the correct session.</li><li>Regenerate outputs and restart localhost.</li></ul>

<h2>Need help with Amplify?</h2>

<p>Terry Hunt Dev diagnoses Amplify configuration and authorization failures through <a href="/services/aws-development">AWS development support</a>. Send the error category and environment name through the <a href="/contact">contact page</a>, but do not send tokens or private endpoint credentials.</p>

Fix amplify_outputs.json localhost problems by identifying the backend, checking endpoints and auth modes, refreshing sessions, and regenerating branch outputs.

Fixing amplify_outputs.json Problems on Localhost

Trace localhost 401, DNS, empty-data, and login failures back to the Amplify backend that generated amplify_outputs.json.

AppSync Resources & Benchmarks

Planning Authorization Rules in Amplify Gen 2 Data

Fixing amplify_outputs.json Problems on Localhost

Need hands-on help with AppSync?