Skip to main content

Notification API Authentication

Summary​

The native Notification API registers no authentication. The compatibility controllers on the monolith require it. Authentication for Notification is therefore a property of which surface a caller reaches, not of the module.

Audience​

Security reviewers, engineers, architects, QA and support.

Native surface​

Program.cs contains no AddAuthentication call, no authentication scheme configuration, no JWT bearer registration and no UseAuthentication middleware call. NotificationEndpoints.cs contains no [Authorize] attribute and no RequireAuthorization call on any group or handler.

Every one of the 17 native operations — including the administration, audit, statistics and test-hook endpoints — is anonymous in the reviewed source.

There is consequently no claims principal available to a native handler. Nothing in the native surface reads HttpContext.User, and no handler extracts a subject, email, role, tenant or scope claim.

Compatibility surface​

Both monolith controllers declare [Authorize] at the class level, so every one of their ten operations requires an authenticated caller.

Claim usage (verified): each notification action resolves the current user by reading the email claim from the principal and matching it against an active user record. When no email claim is present, or no active user matches, the action returns 401. This makes the email claim the effective identity binding for the compatibility surface.

The template controller declares the same attribute but does not perform a per-caller lookup in the reviewed actions.

Middleware ordering​

The native pipeline places the correlation middleware first, then Swagger and its UI, then the endpoint mappings. No authentication or authorization middleware appears at any position. See request lifecycle.

Security boundary​

Because the service does not authenticate, any access control that exists must be applied before the request reaches it — at the gateway, at the network boundary, or by the monolith when traffic stays on the legacy path. This matches the private-network mesh posture recorded across the platform.

The reviewed gateway configuration for the notification routes declares proxy routes and clusters; no authentication requirement is declared on those route entries themselves. What an enclosing deployment enforces is not asserted here and is classified Requires confirmation.

Missing enforcement (verified)​

  • No authentication scheme is registered in the native service.
  • No native endpoint declares an authentication requirement.
  • No native handler reads a claims principal.
  • The test hooks, which can inject events and publish to the shared bus, are anonymous.
  • The audit, failed-queue and statistics endpoints, which return cross-tenant operational data, are anonymous.

Classification​

Partial — implemented on the compatibility surface, Not implemented on the native surface.

Requires confirmation​

Whether the gateway authenticates notification routes in any deployment, and whether in-service authentication is planned for the native surface, require confirmation.

See Also​

Keywords​

  • Notification API
  • Authentication
  • Draft API documentation

Source References​

  • microservices/src/notification-service/Program.cs
  • microservices/src/notification-service/Api/NotificationEndpoints.cs
  • Controllers/NotificationsController.cs
  • Controllers/NotificationTemplatesController.cs
  • microservices/src/gateway-api/Program.cs

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-21
  • Review cycle: Quarterly