Skip to content

SYSTEM Cited by 5 sources

Amazon Cognito

What it is

Amazon Cognito is AWS's managed identity service — user directory + OIDC/OAuth-compatible authentication for web / mobile / machine-to-machine clients. Issues JWTs (ID + access + refresh tokens); supports federation (SAML, OIDC, enterprise IdPs like Okta); supports the OAuth client-credentials flow for service-to-service.

Core constructs

  • User pool — a directory of end-user identities. Supports email/password, SMS MFA, social IdP federation, SAML/OIDC federation.
  • Machine-to-machine user pool — user-pool variant that issues tokens via OAuth client-credentials to services (not end-users).
  • Identity pool — separate construct for issuing temporary AWS credentials to authenticated users (not used in the Convera article).
  • Pre-token-generation Lambda trigger — a hook Cognito invokes between authentication and token issuance, allowing custom attributes to be added/modified in the access token and/or ID token. See pre-token-generation-hook.

Token shape

Cognito issues two tokens on authentication:

  • ID token — OIDC identity assertion. Carries claims about who the user is (sub, email, custom identity attributes).
  • Access token — OAuth authorization grant. Carries claims about what the user is allowed to do (cognito:groups, custom authorization attributes).

The pre-token-generation hook typically customizes the access token with authorization-relevant attributes fetched from an application database, so downstream authorizers can evaluate without a second round-trip.

Why it appears with Verified Permissions

Convera's architecture uses Cognito as the identity + token issuer and AVP as the authorization engine. AVP's IsAuthorizedWithToken API natively understands Cognito JWTs — it maps token claims to Cedar principal attributes. Pairing is explicitly called out in the AWS Architecture Blog as one of the reasons Convera chose AVP: "Direct integration with AWS services like Amazon Cognito and Amazon API Gateway." (Source: sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization)

Flows used in Convera

  • Customer-facing: Cognito user pool, users log in directly, pre-token hook reads roles from RDS and enriches the JWT.
  • Internal users: Cognito user pool federates from Okta, pre-token hook reads attributes from DynamoDB and customizes the access token.
  • Machine-to-machine: separate m2m user pool, OAuth client-credentials grant, access tokens carry service identifier, tier, allowed operations, rate limits.
  • Multi-tenant: per-tenant Cognito pool with a custom tenant_id attribute; pre-token hook looks up user_id → tenant_id in DynamoDB and injects tenant_id as a JWT claim.

Caveats

  • Cognito vs IAM: Cognito is application identity; IAM is AWS-resource identity. They interoperate but serve different purposes.
  • Pre-token hook is invoked per authentication, not per request — attributes fetched there are pinned for the life of the access token (typically minutes to hours). Attribute changes mid-session require token refresh.
  • Cognito has regional boundaries and per-pool user limits that are not discussed in the Convera source.

Seen in

  • sources/2026-09-18-aws-how-csiro-built-scalable-cost-optimized-genomic-variant-querying-on-aws — Cognito as the identity substrate for sBeacon's zero-trust + RBAC model. A Cognito user pool issues the JWTs that the API Gateway COGNITO_USER_POOLS authorizer validates before any Lambda runs. Authorization uses Cognito group membership mapped to disclosure tiers: sbeacon-boolean-access (exists true/false) → sbeacon-count-access (aggregate counts) → sbeacon-record-access (full variant + sample names) → sbeacon-admin (+ dataset management). The JWT carries group memberships as claims; the query Lambda reads them to set requested_granularity / include_details and passes both to performQuery, which computes only what the tier permits (least privilege) — a boolean-tier user never materializes sample-level data. Auth can be disabled at first deploy (BEACON_ENABLE_AUTH = false) for intentionally public beacons — an explicit operator decision. (Source: sources/2026-09-18-aws-how-csiro-built-scalable-cost-optimized-genomic-variant-querying-on-aws)
  • sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization — Cognito as the identity substrate across four authorization flows (customer direct, internal Okta-federated, machine-to-machine, multi-tenant with tenant_id claim); pre-token Lambda hook as the token-enrichment primitive.
  • sources/2026-04-08-aws-build-a-multi-tenant-configuration-system-with-tagged-storage-patterns — Cognito as identity layer in a multi-tenant config service. Canonical surfacing of two custom attributes: custom:tenantId (immutable — declared at user-pool creation so tenant membership is cryptographically pinned and cannot be changed by an admin) + custom:role (mutable — for app-side RBAC). The service's CognitoJwtGuard validates against JWKS; TenantAccessGuard confirms user-to-tenant mapping; service never accepts tenantId from request params. Canonical realization of jwt-tenant-claim-extraction: "Critical security design: the service never accepts tenantId from request parameters."
  • systems/amazon-verified-permissions — authorization engine paired with Cognito.
  • systems/aws-lambda — substrate for the pre-token hook.
  • systems/aws-iam, systems/aws-sts — the IAM-role / temporary-credential machinery behind Cognito identity pools.
  • pre-token-generation-hook — the JWT-enrichment pattern.
  • lambda-authorizer — the downstream consumer of Cognito JWTs.
  • cognito-group-to-iam-role-mapping — using a Cognito identity pool to turn user-pool-group membership into per-tenant IAM role credentials (PACIFIC pattern). See sources/2026-04-22-aws-pacific-multi-tenant-sovereign-pcf-exchange-catena-x.
  • per-tenant-oauth2-exchange-endpoint — PACIFIC also uses Cognito app clients to mint EDC-handshake-gated OAuth2 tokens for per-tenant cross-company data-exchange endpoints.
  • dual-token-session-bridge — Cognito JWT validated server-side and exchanged for an application session token; the game-server-identity-bridge instance where Cognito's sub claim becomes the Nakama user ID. (Source: sources/2026-06-29-aws-dual-token-authentication-for-nakama-game-servers)
  • jwks-cache-with-thundering-herd-protection — caching Cognito's JWKS with mutex + time-guard to prevent stampede on key rotation.
  • dual-token-authentication — the two-token-lifecycle separation pattern with Cognito as identity provider.
Last updated · 766 distilled / 2,225 read