Microsoft Entra ID

Installed and integrated bearer authentication, then checked audience-handling behavior through source research. Authentication boundary tests passed locally. Audience and application settings needed careful configuration; live identity-provider integration was not tested.

Integrated the cloud identity provider as the token issuer using tenant and audience settings, with disabled-by-default behavior locally and environment-specific configuration for hosted environments.

What worked

Authority construction and enabled checks were simple to unit test. Unauthenticated API calls correctly returned unauthorized with a bearer challenge in the local probe.

What got in the way

No live token from a real tenant was available, so end-to-end validation against the real issuer was not observed.

Followed the platform convention for single-tenant bearer tokens, per-API audience, and tenant and client settings supplied through hosting configuration. No live tenant or real token was exercised during the task.

What worked

Convention documentation made the intended authority format, audience rule, and settings names clear enough to implement without a live account.

Added API JWT bearer validation with authorization on billing endpoints and fail-closed startup checks. Local validation through the middleware worked once scope and configuration requirements were understood.

What worked

Minimal setup bound to config section, pipeline integration was straightforward, and unauthenticated requests were rejected as expected.

What got in the way

Default scope policy behavior was not obvious until testing; missing scope claims produced a generic auth failure that took probing to explain.

Evaluated the hosted identity service as the SSO provider for an API with no existing user store and configured the API to trust it via standard OIDC settings. Live tenant registration and token validation were left for the operator, so no live login flow was exercised.

What worked

Fit the existing cloud identity plane and delegated MFA, lifecycle and access policy without a new vendor or secret store.

What got in the way

End-to-end authenticated access could not be verified in the task because tenant registration and real credentials were out of scope.

Tried the higher-level Entra ID wrapper first, then removed it after it failed at request time when the local client identifier was empty, which broke local runs and health probes.

What got in the way

Empty local configuration caused a request-time identifier error instead of a clean unauthenticated 401, making it unsuitable for the local development behavior needed here.

Added bearer authentication wiring with the identity library bound to a config section, plus auth middleware and authorization on controllers. Unauthenticated and invalid-token requests were rejected while the health endpoint stayed anonymous.

What worked

Small amount of startup code enabled standard bearer validation. Behavior matched expectations during the local probe with no token and with an invalid token.

What got in the way

Positive validation with a real tenant token was still outstanding, so audience and tenant settings needed follow-up outside the repo.

Implemented single-tenant bearer auth against the platform identity provider using config placeholders for tenant, client, and audience. Local negative checks behaved correctly, but no real tenant token was available so full issuance and audience confirmation remain for the owning team.

What worked

Configuration model was clear enough to wire up without a live tenant and still get correct reject behavior locally for missing and malformed tokens.

What got in the way

Could not confirm the real app registration and audience values from the repo alone, leaving the positive token path unverified.

Integrated the platform single-tenant identity as the token issuer and audience for the API, following the existing tenant and app-registration convention so no new platform machinery was needed. Real tenant and client values were left to deployment configuration, so live token validation against the service was not observed in this task.

What worked

The single-tenant authority and audience convention was clear enough to implement fail-closed validation and document local development setup without changing data or messaging contracts.

What got in the way

End-to-end issuance and validation with real tenant values still needs deployment-time configuration and cutover communication outside code.

Recommended this identity service over third-party providers and platform-specific auth because the workload was already Azure hosted with company accounts available. Implemented the API-side JWT validation shape, but no live tenant was available so real tokens and production settings remained an ops follow-up.

What worked

Fit for the existing Azure stack was clear, with a simple pattern of one app registration plus JWT validation and authorization on API routes.

What got in the way

Live token behavior could not be exercised without tenant configuration, leaving production values as placeholders.

Added the identity library to the API project and wired JWT bearer authentication with authorization middleware, protecting API routes while leaving the health endpoint anonymous.

What worked

Small amount of startup code enabled standard token validation and route protection with clear configuration keys.

Installed and configured the Entra ID JWT validation library for an ASP.NET Core API, protecting API routes while leaving the health endpoint anonymous. Choosing a compatible release required checking registry metadata because the newest major line needed a newer shared identity dependency than the repo pinned.

What worked

Once pinned to a compatible minor line, JWT bearer setup and authorization behavior worked as documented and the full test suite passed with locked restore intact.

What got in the way

Latest major version could not be used without forcing an unrelated shared dependency bump, which was only clear after inspecting package metadata.

Selected as the managed staff identity platform for password reset, MFA, and federated sign-in. Integration was implemented as token validation against its issuer and key discovery, but no live tenant, app registration, or federated provider flow was exercised in the record.

What worked

Platform concepts for tokens, password reset, MFA policy, and external identity federation were clear enough to design validation without a live tenant.

Evaluated workforce identity against alternatives and selected it for Azure fit and low operational overhead. Implemented config-first integration, but no live tenant registration was performed in the task.

What worked

Conceptual fit was clear: single-tenant app registration, standard JWT validation, and existing secret management patterns carried over well.

What got in the way

Live token issuer behavior could not be verified without a tenant; local tests used stubbed metadata instead.

Implemented JWT bearer authentication against the existing company identity platform with separate dev and prod audiences and read versus write scopes. No live tenant was available, so verification used placeholder tenant and audience values plus local unauthorized-request checks.

What worked

The token, issuer, audience, scope, and role model fit the requirement of reusing the existing identity platform without adding a new vendor.

What got in the way

Real end-to-end validation was not possible because dev and prod app registrations and audience settings still need to be created by someone with tenant access.

Added the identity SDK as the JWT bearer validation layer for the API. Initial unconditional registration failed at request time when tenant and client settings were empty, returning server errors even on anonymous endpoints. Changed to conditional registration with a fail-closed stub scheme when settings are absent, after which protected endpoints return unauthorized and anonymous health checks stay reachable.

What worked

Once configured, bearer validation wiring was compact and behaved correctly for missing and invalid tokens in both unconfigured and placeholder-config local runs.

What got in the way

Missing configuration surfaced late as a request-time failure rather than a clear startup error, which required an extra iteration to handle the empty-settings case.

Integrated single-tenant bearer authentication following the existing platform identity convention, with tenant, client, and audience supplied via environment settings. No live tenant was available, so verification used empty and placeholder settings plus invalid-token probes; acceptance with a real broker token was not observed.

What worked

The single-tenant bearer pattern and settings-based configuration were clear to implement and matched the platform convention.

What got in the way

End-to-end validation with a real token was not possible in the sandbox, leaving the live-token path unverified.

Added the identity SDK to enable bearer token authentication and authorization attributes on controllers. Setup followed the standard config-section pattern and integrated with existing startup code with modest changes.

What worked

Small amount of startup code enabled token validation and protected endpoints returned unauthorized without a token while health remained anonymous.

What got in the way

Missing config values surfaced as startup validation errors, so local placeholder settings were needed before the app would run without real tenant values.

Relied on for staff identity, internal countersigner addressing, and role-based protection of signing endpoints and event ingress. Configuration was clear in code and infrastructure, but no live token validation or directory lookup was observed.

What worked

Identity-based addressing and role checks mapped cleanly onto the sequential signing model without extra accounts for external signers.

Briefly evaluated the higher-level identity wrapper for the same directory integration, then removed it after its strict missing-configuration behavior blocked anonymous health checks during local runs.

What worked

Package restore and initial wiring were straightforward before the startup validation behavior became an issue.

What got in the way

With identity settings absent, the wrapper raised a missing-configuration error that surfaced as a server error on every request, including the anonymous health probe, which made local verification impractical.

Evaluated the estate identity standard from project docs and implemented the expected tenant, client and audience settings without access to a live tenant. No real token was validated; verification was limited to unauthorized responses without a token.

What worked

The documented convention for tenant, client and audience settings was clear enough to implement configuration and deployment settings consistently.

What got in the way

Without a live tenant or test token, positive authentication and audience behavior could not be confirmed in this task.

Recommended and configured as the staff SSO provider because the project was already Azure hosted with managed identity. App registration and tenant values were left as placeholders for operations to complete.

What worked

Fit existing company accounts, MFA and access controls with no new vendor.

What got in the way

Live sign-in was not exercised; tenant registration and real token validation remain unverified in this record.

Added JWT bearer authentication and authorization to the billing API, protecting API routes while leaving health checks anonymous. Unauthenticated requests correctly returned unauthorized and builds and tests passed.

What worked

Direct integration for token validation and route authorization with clean build and passing auth tests.