Remote identity consumer

The authority owns login, refresh, identities, membership, permission administration, signing keys, revocation and identity migrations. An application consuming identity must not register the authority's controllers or access its database.

The revised AddGrydAuthTokenValidator now delegates to AddGrydAuthRemoteConsumer. This is a breaking registration change for applications relying on its former full infrastructure. Authority hosts continue to use AddGrydAuth; consumers reference GrydAuth.Infrastructure only. These APIs require the release containing this change; they are not available in historical 5.0.2.

builder.Services.AddGrydAuthRemoteConsumer(builder.Configuration);
// Normal routing, authentication and authorization middleware are still required.

{
  "GrydAuth": {
    "Consumer": {
      "Authority": "https://identity.example.com",
      "Issuer": "GrydAuth",
      "Audience": "Nexio",
      "TimeoutSeconds": 5,
      "AllowLoopbackHttp": false
    }
  }
}

The consumer sends the bearer to POST /api/v1/consumer-identity over HTTPS for each authenticated request. Redirects and cookies are disabled. The authority validates the signature, issuer, audience, expiry, revocation, token version, active user and current tenant membership, and resolves permissions from current authority data. The consumer validates the returned contract and expected identity scope. It does not locally verify the signature; trust relies on the configured authority and TLS. No private key, identity connection string, identity repository or periodic identity job is registered.

The authority endpoint requires GrydAuth:TokenValidation:CacheFailureMode=FailSecure, a valid tenant access token and active membership. Failure of required verification never grants access. The consumer bounds response size to 64 KiB, claim count to 512 and network time to 1–30 seconds. It never logs tokens or response bodies. Authentication tickets carry the authority's expiry; long-lived transports must also implement their expiration and revocation lifecycle.

HTTP is allowed only for an explicit loopback development configuration. There is no fallback to self-issued tokens, cached success or caller-supplied tenant IDs. Availability and request volume of the authority must be measured as part of the consuming application's deployment.

Integration tests run the authority with PostgreSQL and Redis and cover tampered signature, wrong issuer/audience, expiry, revoked token and removed membership. Consumer tests cover registration without identity storage, malformed responses and unavailable authority. Business company grants remain the consumer's responsibility in addition to the platform permission ceiling.

Browser session validation

The authority's GET /api/v1/auth/validate is a read: it validates an access token or a tenant selector without consuming the selector. Its authorization handler is registered independently of MultiTenancy:IsEnabled. Active user/membership, token types, revocation and prior-use checks still apply. Mutation endpoints retain mandatory consumption; Redis uses an atomic conditional write with expiry, while the memory fallback protects only one process. A cache failure cannot grant access. Integration regressions cover repeated validation followed by switch, absent/false multi-tenancy configuration, revoked identity/membership and simultaneous attempts to consume the same selector.