50 lines
2.3 KiB
Markdown
50 lines
2.3 KiB
Markdown
|
# ADR-001: Provider-Specific Module Naming (httpauth-firebase)
|
||
|
|
|
||
|
|
**Status:** Accepted
|
||
|
|
**Date:** 2026-03-18
|
||
|
|
|
||
|
|
## Context
|
||
|
|
|
||
|
|
An auth middleware module originally named `httpauth` was designed to be
|
||
|
|
provider-agnostic: it defined a `TokenVerifier` interface and duck-typed
|
||
|
|
`firebase.Client` so the module never imported Firebase directly. The intent was
|
||
|
|
that any JWT provider could be supported by implementing `TokenVerifier`.
|
||
|
|
|
||
|
|
Under global ADR-001, framework modules import their named dependencies directly
|
||
|
|
rather than duck-typing them away. An auth module for Firebase should import
|
||
|
|
`firebase.google.com/go/v4/auth` directly, since that is its explicit purpose.
|
||
|
|
This raises the naming question: if the module imports Firebase, should it still be
|
||
|
|
called `httpauth`?
|
||
|
|
|
||
|
|
## Decision
|
||
|
|
|
||
|
|
The module is named **`httpauth-firebase`**:
|
||
|
|
|
||
|
|
- Go module path: `code.nochebuena.dev/go/httpauth-firebase`
|
||
|
|
- Directory: `micro-lib/httpauth-firebase/`
|
||
|
|
- Package name: `httpauth` (short import alias; the module path carries the provider name)
|
||
|
|
|
||
|
|
A different auth provider would live in `httpauth-auth0`, `httpauth-jwks`, etc.
|
||
|
|
All `httpauth-*` modules converge on the same output contract: `rbac.Identity` stored
|
||
|
|
in context via `rbac.SetInContext`.
|
||
|
|
|
||
|
|
The `TokenVerifier` interface is retained **solely for unit-test mockability** —
|
||
|
|
not for provider abstraction. In production, `*auth.Client` from
|
||
|
|
`firebase.google.com/go/v4/auth` satisfies `TokenVerifier` directly without any
|
||
|
|
adapter.
|
||
|
|
|
||
|
|
## Consequences
|
||
|
|
|
||
|
|
- The module name is honest: scanning the module list, a developer immediately knows
|
||
|
|
this is Firebase-specific and not a generic auth abstraction.
|
||
|
|
- Other auth providers are accommodated by creating sibling modules
|
||
|
|
(`httpauth-auth0`, etc.) with identical output contracts, not by implementing an
|
||
|
|
interface in this module.
|
||
|
|
- The `TokenVerifier` interface remains exported so test code outside the package can
|
||
|
|
implement it (`mockVerifier` in `compliance_test.go`). Its presence does not imply
|
||
|
|
that swapping providers at runtime is a supported pattern.
|
||
|
|
- Applications that switch from Firebase to another provider replace the module
|
||
|
|
import; the rest of the auth stack (`EnrichmentMiddleware`, `AuthzMiddleware`) and
|
||
|
|
all business logic remain unchanged because they depend on `rbac.Identity`, not on
|
||
|
|
Firebase types.
|