Phoenix 1.8 introduces Scopes as a structured container for request context (current user, tenant, permissions) that gets passed into domain/context functions to enforce data boundaries. The post explains how mix phx.gen.auth generates a default scope struct, wires it into the browser pipeline via a plug, and provides a matching on_mount hook for LiveView. It then covers how Permit.Phoenix builds on top of Phoenix Scopes to add repeatable authorization enforcement across controllers and LiveViews, handling permission checks, resource preloading, and unauthorized outcomes consistently. A decision guide helps developers choose between raw scopes alone versus adding Permit.Phoenix based on complexity of access rules.
Table of contents
What are Phoenix Scopes?Authentication vs scoping vs authorizationScopes generated by mix phx.gen.authScopes are not a complete authorisation systemHow Permit.Phoenix works with Phoenix ScopesWhy use Permit.Phoenix instead of only raw scopes?Choosing the Right LayerSort: