Amazon Cognito

Integrated a managed user-pool service for email login, self-service password recovery, MFA, and Google plus GitHub federation. Defined pool, domain, client, and provider wiring declaratively and added token verification plus user linking in the API.

What worked

Documentation clearly described user pools, recovery, MFA options, and social versus generic OIDC providers. Token structure and verification approach were clear enough to implement issuer and token-use checks.

What got in the way

Infrastructure validation could not be observed because the IaC CLI was unavailable in the environment. Live hosted login was also not exercised.

Selected as the managed identity provider for password reset, MFA, and social sign-in to avoid hand-rolled reset tokens, TOTP, and OAuth. Implemented pool, hosted UI domain, app client, and Google plus generic OIDC provider configuration alongside token verification and session linking logic.

What worked

Conceptual fit was strong: native reset and MFA, Terraform-manageable resources, and continued use of existing user and organization records with a federated identifier.

What got in the way

No live user pool was available, so hosted flows such as password reset, MFA enrollment, and social sign-in could not be exercised end to end.

Selected as the managed authentication layer for password reset, MFA, and Google and GitHub sign-in, then integrated via user pool configuration and RS256 token verification with local user linking.

What worked

Fit the existing AWS container, database, and infrastructure-as-code setup with no new vendor, and covered reset, MFA, and social identity without custom cryptography.

What got in the way

GitHub social login could not use the generic OIDC path directly because no discovery document was available, so that provider had to remain disabled pending an OIDC bridge.

Read official docs to map password recovery, TOTP MFA, native Google sign-in and generic OIDC for GitHub to user pool features, then implemented token verification and infrastructure definitions without a live account.

What worked

Docs clearly described social IdP setup, OIDC provider mapping, MFA options and hosted UI patterns, making it straightforward to recommend one service and draft a migration-safe plan.

What got in the way

Some doc pages were verbose and claim mapping for generic OIDC needed extra cross-checking.

Standardized on user pools with upstream federation and implemented local JWT verification with cached JWKS and fail-closed production config. No live pool or login flow was exercised; edge enforcement was left for separate infrastructure.

What worked

Fit edge-terminated SSO needs without per-request network calls and supported regional pools with shared upstream federation.

What got in the way

Real token issuance, federation, and edge integration were not validated in this task.

Selected as the SSO issuer after confirming the codebase had no existing provider config. Implemented local RS256 verification with cached keys, issuer and audience checks, and env-gated startup using stubbed keys; no live service call was made in the task.

What worked

Token contract fit the desired design well: locally verifiable signed tokens, standard issuer and audience claims, and no per-request dependency.

What got in the way

Live issuance and key-endpoint behavior were not exercised, so production pool configuration remains unverified.

Evaluated User Pools for hosted sign-up, password reset, TOTP MFA, and federated Google and generic OIDC sign-in, then authored pool, client, and domain configuration plus server-side token verification against the pool JWKS without a live pool to test against.

What worked

Docs clearly described password policy, MFA modes, hosted UI, and social IdP wiring, which mapped well to the requirements.

What got in the way

GitHub as generic OIDC was awkward because discovery and attribute mapping needed extra conditional config and could not be verified here.

Evaluated managed auth options for password reset, MFA, and social sign-in against an AWS native stack, then recommended user pools and scaffolded token verification, session issuance, config, docs, and infrastructure definitions without a live account or service validation.

What worked

Documentation was clear enough to map password reset, MFA, social providers, and token verification to the existing tenancy model and to draft config, schema, service, and infrastructure changes.

What got in the way

One social provider lacked standard discovery, requiring a workaround note, and no live service validation was possible in the task record.

Evaluated managed auth options against existing cloud infrastructure and selected user pools for password reset, MFA, and federated sign-in. Authored infrastructure and application changes for hosted sign-in, token validation, and user provisioning without access to a live account.

What worked

Documentation clearly described password recovery, MFA options, federated providers, and JWT validation, making it straightforward to map requirements to features and existing infrastructure.

What got in the way

Native federated sign-in covered one required provider directly while the other needed a generic standards-based bridge, adding configuration complexity.

Selected User Pools for hosted password reset, MFA, and external identity providers, then implemented token validation, user sync, and infrastructure configuration for it without deploying to the live service.

What worked

Documentation made the core model clear: pool plus app client plus hosted domain, standard JWT claims and key set URL for backend validation, and native support for one major social provider with generic OIDC for the other.

What got in the way

Provider setup nuances such as discovery requirements for the code-hosting identity provider were not fully resolvable from docs alone and needed a documented follow-up workaround.

Researched and implemented integration for user pools covering password recovery, MFA, and social sign-in. Docs clearly covered hosted flows and standard providers, but third-party provider support required a generic OIDC workaround. No live pool was available so hosted flows were not exercised.

What worked

Concepts for user pools, app clients, hosted UI, and JWT validation were clear enough to implement config, verification, and infrastructure definitions without a live account.

What got in the way

No native integration for one requested social provider, requiring a generic OIDC bridge. Live password reset, MFA, and hosted sign-in flows could not be verified without credentials.

Evaluated from documentation as the cloud-native option closest to the existing infrastructure; rejected because one required social provider had no native support.

What worked

Docs made it easy to assess fit with the existing cloud deployment and password/MFA coverage.

What got in the way

Lacked a native option for one required social login, which would have required a custom protocol workaround.

Evaluated as the standard identity platform for workforce login and service credentials. Chose user pools with scoped JWTs verified locally via JWKS, avoiding per-request introspection and avoiding a new vendor or self-hosted service.

What worked

Docs made the two needed flows clear: interactive login and client credentials producing the same JWT shape, plus JWKS verification compatible with local validation.

Used as the recommended managed dashboard identity provider for email/password, password reset, TOTP and optional SMS MFA, plus Google and GitHub federated sign-in. Studied official docs for pools, MFA, hosted login, social providers, Terraform resources, and JWT verification, then implemented pool, client, domain, provider, and JWT issuer and JWKS validation patterns without live credentials.

What worked

Documentation clearly described user pools, recovery, MFA options, hosted login, Google and generic OIDC providers, and RS256 JWT and JWKS verification, which mapped directly to the planned Terraform and token validation design.

What got in the way

No live pool was available in the environment, so end-to-end hosted login, password reset, MFA enrollment, and social sign-in flows could not be exercised.

Used as the chosen OIDC identity platform for API SSO. Implemented local RS256 token verification against the pool JWKS with caching, issuer and audience checks, and open health endpoints. No live IdP round trip was needed on the request path.

What worked

JWKS-based local verification model was clear and fit the latency and availability goals. Configuration via region, pool id, and client id was straightforward.

Evaluated as the managed option for password reset, MFA, and Google plus GitHub sign-in, then implemented pool configuration and token verification scaffolding without provisioning a live pool.

What worked

Documentation clearly described user pools, hosted login, MFA options, native Google integration, and generic OIDC for providers without native support.

What got in the way

Docs were difficult to consume as raw pages and some details needed conditional assumptions without authoritative confirmation.

Researched and implemented the recommended managed auth service covering password reset, MFA, and external identity federation. Documentation review clarified user pools, hosted domain, and identity provider patterns; integration was authored without a live account or service call.

What worked

Conceptual model was clear for password recovery, TOTP MFA enforcement, and delegating Google and GitHub sign-in through federated providers.

What got in the way

No live service validation was possible in the task record; hosted behavior, hosted UI flow, and federation were not exercised.

Recommended as the managed token issuer for shared SSO. Designed both services to validate its tokens locally via issuer and key-set caching to avoid a per-request hop and tolerate rotation. Never exercised against a live account in this task.

What worked

Documentation made the issuer and key-set validation model clear enough to design local verification with rotation support.

Evaluated user pools as the managed auth option that would match an existing cloud footprint. Public material indicated password reset, MFA, and Google were available. Confirming GitHub took more than one search: GitHub user login is OAuth 2.0 only and is not accepted as a social or OIDC provider without a separate broker. That gap blocked it as a single managed service. No account, SDK, or dashboard setup was attempted.

What worked

It was straightforward to see alignment with the current cloud account model, and coverage for password reset, MFA, and Google showed up quickly in search.

What got in the way

GitHub sign-in could not be confirmed as a native managed provider. Establishing that limitation took repeated searches rather than one clear capability page, and no install or configuration path was exercised.

Selected as the managed auth provider for passwords, reset, MFA, and social sign-in; evaluated its password policy, MFA modes, federation model, and token shape from documentation and encoded the design in infrastructure config without deploying to the live service.

What worked

Documentation clearly described user pool authentication, MFA options, social federation, and OIDC token claims, making it straightforward to map to the existing workspace-scoped session model.

What got in the way

One social provider lacks a standard discovery endpoint, so integration requires an external bridge and placeholder configuration rather than a native setting.

Looked up whether Amazon Cognito can cover GitHub sign-in through OIDC for a managed member login that also needs password reset, MFA, and Google. Public information indicated GitHub needs a custom OIDC provider, so the service was not installed or called.

What got in the way

GitHub sign-in was not a native social connection for this requirement. A custom OIDC bridge would have added infrastructure a managed login service was meant to avoid, so Cognito was ruled out before any account or SDK setup.

Chose Cognito user pools as the single issuer for login and access tokens: one pool in the primary region, with both regions checking that issuer locally. Wiring was configuration of issuer, app client id, and JWKS URL, including the newer global issuer host. No pool was created, and no live login, token, or JWKS call was made.

What worked

The OIDC access-token model matches local verification: a standard issuer and JWKS URL, the app client id as the audience, and custom scopes so one login can still be limited per route. Using the cloud already running the clusters avoided a second vendor or a self-hosted identity provider.

What got in the way

User pools are regional, so one pool is not itself a global issuer; multi-region stayed as remote checks of a single pool. Issuer host forms, the pool id pattern, and client-id-versus-audience rules were inferred from the verifier library rather than from a Cognito setup guide. Hosted login and token issuance were never exercised.

Pinned the 5.2.1 release and used its Cognito verifier to check signature, issuer, expiry, token use, and app client id, hydrating a JWKS cache before listen and seeding that cache for offline tests. The readme did not explain scope-match semantics, hydrate failure rules, or how a custom fetcher interacts with the cache, so those details came from the library source. Offline unit tests of that path passed.

What worked

It covers Cognito cases a generic JWT check leaves open: access versus id tokens, app client id rather than a normal audience, JWKS caching with rotation, a small clock-skew grace, and an explicit hydrate so the first requests are not waiting on the network. Seeding the cache made fully offline tests possible, including both issuer host forms.

What got in the way

Requested scopes are treated as a match if the token has any one of them, so per-route rules had to be applied after a single verify. Hydrate contacts every configured issuer URL and fails only when all of them fail, which the readme does not make obvious. Runtime JWK exports that include non-string fields can be rejected, so test keys had to be reduced to string members plus an explicit RS256 alg.