Notification Authentication and Authorization
Summary
The Notification Service registers no authentication or authorization. There is no AddAuthentication, AddAuthorization, UseAuthentication, UseAuthorization, JWT bearer configuration, [Authorize] attribute or RequireAuthorization on any endpoint in the reviewed source. All endpoints are anonymous.
Security boundaries
Access control, when present, is expected upstream at the gateway or the legacy monolith path, consistent with the private-network microservice-mesh posture used across the platform. The service itself does not verify caller identity.
Identity in requests
The inbox endpoint identifies a recipient by a recipientRef query parameter and an optional tenantId; neither is verified against an authenticated principal. Tenant context on consumed events comes from the message header (TenantId), not from a validated token.
Tenant and claims
There is no claims principal, no tenant-claim extraction and no per-tenant authorization check inside the service. Tenant scoping is a data-filter concern (see tenant isolation), not an authorization decision.
Missing enforcement (verified)
- No authentication scheme is configured.
- No authorization policies or role checks exist.
- Administrative and diagnostic endpoints (retry, failed list, audit, stats, template CRUD, test hooks) are anonymous.
- Recipient identity on the inbox endpoint is caller-supplied and unverified.
Requires Confirmation
Whether the gateway enforces authentication for notification routes, how recipient identity is trusted in production, and whether in-service authorization is planned require confirmation.
Source References
microservices/src/notification-service/Program.csmicroservices/src/notification-service/Api/NotificationEndpoints.csmicroservices/src/gateway-api/Program.cs
Related Articles
See Also
Keywords
Authentication, authorization, anonymous endpoints, security boundary, missing enforcement.
Revision Information
- Status: Draft
- Last reviewed: 2026-07-21
- Next review: 2026-10-21