Auth and Authz
Authentication establishes an AuthContext; authorization decides whether that identity may invoke a method. Keep those decisions separate in the interceptor chain even when they are configured together.
Choose the trust boundary
| Boundary | Start here |
|---|---|
| Clients send bearer JWTs directly | JWT authentication |
| A trusted gateway verifies credentials first | Gateway authentication |
| A web application resolves a session | Session authentication |
| Internal services attach outgoing identity | Client interceptors |
| Handlers need the authenticated identity | Auth context |
Choose authorization ownership
Use proto-based authorization when access policy belongs with the RPC contract. It keeps public methods, roles, scopes, and the runtime resolver on the same generated descriptor. Use code-based authorization for dynamic rules or legacy services whose policy cannot live in proto options.
interceptors: [
createErrorHandlerInterceptor(),
createJwtAuthInterceptor({ jwksUri, skipMethods }),
createProtoAuthzInterceptor({ defaultPolicy: 'deny' }),
...createDefaultInterceptors({ errorHandler: false }),
]The security invariant is error handling → authentication → authorization → remaining behavior. Public-method discovery and exact factory fields are deliberately not duplicated here; use the focused guide and generated interfaces such as JwtAuthInterceptorOptions.
Learn, configure, inspect
- Learn the model here and in ADR-024.
- Configure a concrete trust boundary in the focused guides above.
- Use the
@connectum/authmodule hub and generated API for exact symbols.