.png)
Amazon Cognito Integration Guide
Integrate Amazon Cognito user and identity pools with enterprise applications through AWS service APIs, OAuth 2.0/OIDC, JWTs, and selected AWS event mechanisms.
Amazon Cognito integration options at a glance
Amazon Cognito provides regional HTTPS service APIs for user pools and identity pools, using AWS JSON protocols and Signature Version 4 authentication. User pools also expose OAuth 2.0 and OpenID Connect endpoints, issue JWTs, and support federation with SAML and OIDC identity providers. Selected lifecycle and authentication events can invoke AWS Lambda triggers or flow through AWS event services, but Cognito does not provide a universal webhook for every operation. Martini can consume Cognito APIs, validate and route token claims, orchestrate provisioning and reconciliation workflows, and expose APIs for Lambda or other AWS intermediaries.
| Integration point | Supported by Amazon Cognito? | Common use cases | How Martini supports it |
|---|---|---|---|
| HTTPS service APIs using AWS JSON protocol | Limited | Create, update, delete, list, and search Users; manage Groups and User pool clients; initiate authentication flows; and manage User pools or Identity pools. These are operation-oriented AWS service APIs rather than conventional REST resource APIs. | Martini can consume the regional HTTPS APIs from workflows, construct AWS JSON payloads, map responses, apply validation, and expose a REST API façade where required. |
| OAuth 2.0 and OpenID Connect | Yes | Authenticate application users, exchange authorization codes, refresh tokens, and authorize access to protected resources through a configured Cognito user pool domain. | Martini can participate in OAuth-based API designs, pass tokens between systems, and use Cognito-issued tokens when protecting Martini APIs, subject to deployment security configuration. |
| JWTs and token validation | Yes | Validate Cognito-issued ID and access tokens using signing keys, issuer, audience, expiry, token use, scopes, and group claims. | Martini workflows and APIs can extract claims and apply authorization, routing, and business rules without placing sensitive token values in logs. |
| Webhooks and outbound callbacks | Limited | Selected user lifecycle and authentication events can invoke AWS Lambda triggers. Cognito does not provide a general-purpose webhook for every User pool operation. | Martini can expose an API for a Lambda or other AWS intermediary to call, then process, transform, route, and record the event. |
| AWS event routing | Limited | Selected Cognito-related events or service activity can be routed through AWS EventBridge and onward to Lambda, queues, or HTTP-capable intermediary components where event coverage applies. | Martini can consume requests from an AWS intermediary and provide downstream orchestration, reconciliation, and error handling. Required event coverage must be verified for each use case. |
| Pagination and client-side batch processing | Limited | Operations such as listing Users return paginated results. Large synchronizations require client-side iteration, checkpoints, and controlled processing rather than a confirmed general-purpose bulk import or export API. | Martini can orchestrate paginated reads, normalize each page, persist progress, enforce bounded processing, and produce reconciliation results. |
| Authentication | Yes | Administrative service APIs use AWS Signature Version 4 and IAM permissions. User-facing flows use OAuth 2.0/OIDC and JWTs, while Identity pools issue temporary AWS credentials through IAM roles. | Martini can store environment-specific authentication details securely, consume protected APIs, use token-aware workflows, and apply authorization rules. |
| SDKs and AWS tooling | Yes | AWS SDKs and the AWS CLI support Cognito operations in multiple programming languages and can address AWS-specific signing or service behavior. | Martini can use direct HTTPS calls and, where necessary, custom JVM-compatible logic for signing or an operation that is not conveniently represented in a workflow. |
How Amazon Cognito exposes data and business events
Amazon Cognito service APIs
Amazon Cognito exposes regional HTTPS APIs for User pools and Identity pools. The APIs use AWS JSON request formats and AWS Signature Version 4 with IAM permissions for administrative operations such as managing Users, Groups, clients, and identity resources.
Martini implementation pattern
Martini implementation pattern: Martini consumes the Cognito HTTPS service API from a workflow, supplies region- and environment-specific authentication configuration, maps request and response payloads, applies business rules, and routes errors according to their transient or permanent nature.
Implementation sequence
Amazon Cognito OAuth 2.0 and OIDC
Configured Cognito User pools can provide OAuth 2.0 and OpenID Connect endpoints for managed login, authorization code exchange, token refresh, and protected resource access. Cognito issues signed ID and access tokens.
Martini implementation pattern
Martini implementation pattern: Martini can expose APIs that accept Cognito-issued access tokens, validate the configured token properties, extract scopes or group claims, and route authorized requests to downstream services. Sensitive token material is kept out of operational logs.
Implementation sequence
Amazon Cognito Lambda triggers
Cognito supports Lambda triggers for selected lifecycle and authentication events, including pre-sign-up validation, custom messages, post-confirmation processing, pre-token generation, user migration, and custom authentication challenges. This is selective trigger coverage rather than a universal webhook service.
Martini implementation pattern
Martini implementation pattern: A Lambda function transforms a supported Cognito event into a controlled request to a Martini API. Martini validates the event, maps it to an enterprise User or account model, performs downstream orchestration, and records failures for retry or reconciliation.
Implementation sequence
AWS event routing for Cognito
AWS event services can route selected Cognito-related events or service activity through EventBridge to Lambda, queues, or HTTP-capable intermediary components. Availability and delivery behavior depend on the specific event and resource.
Martini implementation pattern
Martini implementation pattern: Martini receives the normalized event from an AWS intermediary and treats it as one input to an event-driven workflow. Scheduled reconciliation remains available for changes that are not represented by the selected event coverage.
Implementation sequence
Paginated Cognito synchronization
Cognito listing operations, including User retrieval, return paginated results. Cognito does not provide a confirmed general-purpose bulk import or export API, so larger synchronization jobs require client-side orchestration and checkpointing.
Martini implementation pattern
Martini implementation pattern: A scheduled workflow retrieves pages, normalizes Users and Group membership, compares them with a source of truth, and resumes safely after transient failure. Bounded concurrency and backoff help avoid service quota pressure.
Implementation sequence
Common Amazon Cognito integration patterns
Pattern 1: Provision users from enterprise applications
When to use this pattern
Use this pattern when an HR, customer, service-management, or business application is the source of truth for user creation and access changes. It supports controlled provisioning into Cognito User pools and Groups while preserving source identifiers and handling duplicate requests safely.
Integration direction
Example Mapping
| Amazon Cognito Field | Canonical Field | Target Field |
|---|---|---|
| externalSourceId | sourceUserId | custom:sourceUserId |
| givenName | firstName | given_name |
| familyName | lastName | family_name |
Martini implementation pattern
Martini receives an API request or scheduled change, validates required attributes, looks up an existing User before creation, calls the Cognito service API with AWS authentication, assigns Groups according to business rules, and returns the Cognito username or subject identifier. Retryable throttling and AWS service failures use bounded backoff; conflicts and validation failures are routed for correction.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- AWS API authentication
- error handling
Pattern 2: Reconcile Cognito users with a source of truth
When to use this pattern
Use scheduled reconciliation when Cognito changes are not fully covered by selected Lambda triggers or event integrations, or when an enterprise system requires a complete comparison of Users, status, attributes, and Group membership.
Integration direction
Example Mapping
| Amazon Cognito Field | Canonical Field | Target Field |
|---|---|---|
| Username | identityUsername | userName |
| sub | cognitoSubject | externalIdentityId |
| UserStatus | lifecycleStatus | status |
| Enabled | enabled | active |
Martini implementation pattern
A Martini scheduler retrieves Cognito Users page by page, normalizes attributes and membership, compares stable identifiers with the target system, and applies only the required changes. The workflow persists checkpoints, avoids duplicate processing after retries, and produces a report for unresolved mismatches or authorization failures.
Martini capabilities used
- scheduled workflows
- pagination orchestration
- data mapping
- comparison rules
- checkpointing
- monitoring and error handling
Pattern 3: Process selected Cognito lifecycle events
When to use this pattern
Use this pattern for supported post-confirmation, pre-sign-up, custom message, or other selected Cognito trigger scenarios where an event should update an enterprise system. It is not a substitute for an audit stream covering every Cognito operation.
Integration direction
Example Mapping
| Amazon Cognito Field | Canonical Field | Target Field |
|---|---|---|
| triggerSource | identityEventType | eventType |
| userAttributes.email | ||
| userName | identityUsername | externalUserName |
| userPoolId | identityDirectoryId | sourceDirectoryId |
Martini implementation pattern
Lambda transforms the Cognito event into a controlled Martini API request. Martini validates the event, maps the payload, enriches it when necessary, applies routing and idempotency rules, and updates the target application. Failed deliveries are logged with a correlation identifier and can be retried or reconciled without replaying successful work.
Martini capabilities used
- API exposure
- workflow orchestration
- event processing
- data transformation
- idempotency rules
- error routing
Pattern 4: Protect a Martini API with Cognito tokens
When to use this pattern
Use this pattern when internal applications or partners authenticate with a Cognito User pool but need a controlled API façade that applies enterprise authorization and orchestrates multiple downstream services.
Integration direction
Example Mapping
| Amazon Cognito Field | Canonical Field | Target Field |
|---|---|---|
| scope | requestedCapability | authorizationRule |
| cognito:groups | userGroups | routingContext |
| sub | callerSubject | auditActor |
| exp | tokenExpiry | requestValidity |
Martini implementation pattern
The client authenticates through Cognito and calls a Martini API with an access token. Martini validates signature and token claims, applies scope and group-based rules, invokes downstream workflows, and returns a controlled response. Authorization failures are rejected without retry, while downstream transient errors follow the configured retry and error-routing policy.
Martini capabilities used
- API exposure
- JWT-aware authentication
- authorization rules
- workflow orchestration
- data mapping
- error handling
Applications commonly integrated with Amazon Cognito
Amazon Cognito commonly participates in AWS application architectures and enterprise identity flows. Martini can coordinate Cognito with the following named applications and services using APIs, controlled intermediaries, token-aware workflows, and scheduled reconciliation.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Amazon API Gateway | Protect APIs with Cognito user pool authorizers and JWT-based access control while centralizing downstream orchestration. | Amazon Cognito → Amazon API Gateway → Martini | Martini can expose or mediate APIs that receive Cognito-issued access tokens, validate relevant claims, apply routing rules, and call downstream services. API Gateway can remain the AWS-facing entry point where required. |
| AWS Lambda | Execute Cognito user pool triggers, custom authentication logic, and event processing for selected lifecycle events. | Amazon Cognito → AWS Lambda → Martini | A Lambda trigger can transform the Cognito event into a controlled Martini API request. Martini then maps the event, applies business rules, updates enterprise systems, and returns or records an outcome. |
| Amazon S3 | Provide authenticated application users with temporary, policy-controlled access to S3 resources through identity pools and IAM roles. | Amazon Cognito → AWS STS/IAM → Amazon S3 | Martini can coordinate identity-related requests or expose an API façade around application workflows, while Cognito identity pools and IAM determine the temporary permissions granted for S3 access. |
| Amazon DynamoDB | Support application access to DynamoDB through temporary credentials or coordinate Cognito identity information with application data. | Amazon Cognito → AWS IAM → Amazon DynamoDB | Where enterprise synchronization is needed, Martini can consume Cognito APIs, transform identity data, and invoke an approved downstream API or workflow. DynamoDB permissions remain controlled by IAM policies. |
| Salesforce | Synchronize customer, contact, or user lifecycle information with an application identity directory backed by Cognito. | Salesforce → Martini → Amazon Cognito | A Martini workflow can receive Salesforce changes, validate required attributes, create or update Cognito Users, assign Groups, and store the Cognito identifier back in Salesforce. Selected Cognito events can flow back through Lambda. |
| ServiceNow | Coordinate user provisioning or reconciliation when ServiceNow supports service management, access requests, or identity-related workflows. | ServiceNow → Martini → Amazon Cognito | Martini can consume ServiceNow requests, map the requested lifecycle state to Cognito Users and Groups, call the Cognito service API with AWS authentication, and return status or failure details to ServiceNow. |
| Microsoft Entra ID | Federate workforce authentication into Cognito using SAML or OpenID Connect and coordinate related lifecycle processes. | Microsoft Entra ID → Amazon Cognito → Martini | Cognito can act as the configured federation layer for authentication. Martini can separately orchestrate provisioning, reconciliation, or application API access when lifecycle synchronization is required. |
| Okta | Federate workforce or customer authentication into Cognito using SAML or OpenID Connect. | Okta → Amazon Cognito → Martini | Cognito handles the configured federation path, while Martini can consume Cognito APIs or receive selected intermediary events to synchronize users, groups, and application access with enterprise systems. |
How to build a Amazon Cognito integration in Martini
Objective
Configure the AWS region, Cognito resource identifiers, IAM role or credentials, and any OAuth or OIDC settings required by the integration without embedding environment-specific secrets in workflow definitions.
Instructions in Martini
- Select the Cognito User pool or Identity pool operations required by the use case
- Configure region, pool IDs, app client IDs, and domains per environment
- Use IAM permissions and AWS Signature Version 4 for administrative service APIs
- Store secrets and signing credentials through the deployment environment
- Define token issuer, audience, scopes, and group requirements for protected APIs
Objective
Select an input mechanism that matches the required latency and event coverage, recognizing that Cognito Lambda triggers and AWS event integrations cover selected events rather than every User pool operation.
Instructions in Martini
- Use an API request for application-driven provisioning
- Use a Lambda or AWS intermediary for supported Cognito events
- Use a scheduler for complete or periodic reconciliation
- Use a Martini API façade for token-authenticated client requests
- Define a correlation identifier for each request or event
Objective
Call the appropriate Cognito service API or process the event payload, handling AWS JSON formats, paginated results, and current-resource lookups where the event does not contain sufficient data.
Instructions in Martini
- Construct the operation-specific AWS JSON request
- Retrieve the current User, Group, User pool, or Identity pool data when needed
- Continue through pagination tokens for listing operations
- Persist progress for long-running synchronizations
- Classify authorization, validation, conflict, throttling, and service failures
Objective
Use a Martini workflow to coordinate Cognito calls, intermediary events, enterprise systems, validation, enrichment, and response handling as one maintainable integration process.
Instructions in Martini
- Route requests by event type, source system, or business operation
- Add lookup-before-create and duplicate detection logic
- Enrich Cognito events with enterprise context when required
- Keep successful and failed branches explicit
- Use reusable workflow logic for common provisioning and reconciliation behavior
Objective
Translate Cognito attributes, statuses, claims, Groups, and identifiers into the canonical model used by downstream applications while preserving security and lifecycle semantics.
Instructions in Martini
- Map standard and custom Cognito attributes to canonical fields
- Normalize enabled, confirmed, verified, and password-related states separately
- Map Group membership to enterprise access or role rules
- Avoid treating email as a permanent identifier unless the business model guarantees stability
- Do not write JWTs, refresh tokens, or credentials to ordinary logs
Objective
Apply authorization, lifecycle, validation, idempotency, and routing rules before changing Cognito or downstream systems.
Instructions in Martini
- Validate required attributes and allowed status transitions
- Check stable source identifiers before creating Users
- Treat already-existing Users or Group membership as safe outcomes where appropriate
- Check scopes and group claims for protected API requests
- Separate permanent validation and permission failures from retryable service failures
Common Amazon Cognito data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| User pools | Directories that store users, authenticate them, issue tokens, and define application identity behavior. | Martini APIs, Amazon API Gateway, Salesforce, ServiceNow, Microsoft Entra ID, Okta | Martini stores pool identifiers in environment configuration, calls the relevant service operations, and maps pool-level settings or lifecycle outcomes into enterprise models. |
| Users | Individual profiles containing attributes, status, verification state, and authentication-related metadata. | Salesforce, ServiceNow, HR or workforce applications, internal user directories | Martini validates attributes, performs lookup-before-create logic, creates or updates Users, maps status semantics, and handles pagination, conflicts, throttling, and retries. |
| Groups | Collections of Users used for application authorization and association with IAM roles. | Enterprise access-management processes, Salesforce, ServiceNow, application authorization layers | Martini maps source-system roles or access requests to Groups, applies membership rules, and treats already-applied membership as an idempotent outcome. |
| User pool clients | Application registrations that define how applications interact with a User pool. | Web applications, mobile applications, Amazon API Gateway, Martini API façades | Martini can orchestrate approved client-management operations and keep client identifiers, redirect configuration, and scopes environment-specific. |
| Identity pools | Federated identity brokers that exchange trusted identity information for temporary AWS credentials. | Amazon S3, Amazon DynamoDB, AWS STS, IAM-controlled AWS resources | Martini can coordinate identity-related workflows and map identity-pool configuration or outcomes, while IAM policies control the permissions of issued credentials. |
| Identity providers | Configured SAML, OIDC, social, or other supported sources for federation into Cognito. | Microsoft Entra ID, Okta, enterprise applications, customer identity providers | Martini can coordinate configuration or lifecycle processes around provider references, but authentication federation remains governed by Cognito and the provider configuration. |
Authentication and security considerations
AWS service API authentication
Administrative Amazon Cognito operations use regional HTTPS endpoints, the AWS JSON protocol, AWS Signature Version 4, and IAM permissions. Configure the AWS account, region, role or credentials, and operation-level permissions per environment.
User authentication and tokens
User pools support OAuth 2.0, OpenID Connect, signed ID tokens, access tokens, multifactor authentication, and federation with configured SAML or OIDC providers. Validate issuer, signature, audience, expiry, token use, scopes, and relevant group claims.
Credential protection
- Keep IAM credentials, client secrets, signing material, and refresh tokens in secure environment configuration.
- Do not place access tokens or refresh tokens in ordinary workflow logs.
- Use narrowly scoped IAM roles and policies for Identity pool credentials and administrative operations.
Operational considerations for Amazon Cognito integrations
Quotas and pagination
Use bounded concurrency, exponential backoff, and rate-aware processing for Cognito quotas. Listing operations are paginated, so reconciliation workflows must continue until the pagination token is absent and should persist progress for long-running jobs.
Idempotency and lifecycle state
Use stable source identifiers and lookup-before-create logic. Model enabled state, confirmation state, verified attributes, Group membership, and password-related state separately rather than reducing them to one status.
Events and schema changes
Lambda triggers and AWS event integrations have selective coverage and should be combined with scheduled reconciliation when complete synchronization is required. Test changes to standard and custom attributes, required fields, immutable attributes, claims, scopes, and User pool configuration across environments.
Retries and testing
Retry throttling and temporary AWS failures with bounded backoff, but route invalid parameters, missing permissions, expired tokens, and conflicts for correction. Test token-key rotation, duplicate delivery, pagination recovery, authorization failures, and downstream outages before production deployment.
Why use Martini instead of scripts or point-to-point integrations?
Coordinate more than one API call
Scripts often combine Cognito calls, enterprise applications, AWS intermediaries, validation, and reconciliation logic in a single codebase. Martini provides workflows that make these steps explicit and reusable.
Separate mapping from business rules
Martini can map Cognito attributes, claims, statuses, and Group membership into canonical models while applying authorization, lifecycle, and idempotency rules before writing to target systems.
Support multiple operating modes
The same integration approach can support API-driven provisioning, selected Lambda-triggered events, token-aware API façades, and scheduled paginated reconciliation without creating separate point-to-point scripts for each path.
Improve operational control
Centralized error routing, bounded retries, correlation identifiers, monitoring, and environment-specific security configuration make Cognito integrations easier to troubleshoot and maintain as user pools and downstream systems evolve.
Frequently asked questions
Amazon Cognito can be integrated through its regional HTTPS service APIs, which use AWS JSON requests and Signature Version 4, as well as OAuth 2.0/OIDC endpoints and Cognito-issued JWTs. Selected lifecycle and authentication events can flow through Lambda triggers or AWS event-routing services. Larger synchronizations generally use paginated API operations and scheduled reconciliation.
Yes. Martini can integrate with Amazon Cognito by consuming its HTTPS service APIs, using OAuth 2.0/OIDC and JWT-based authentication designs, and receiving requests from AWS intermediaries such as Lambda. Martini can orchestrate provisioning, reconciliation, token-aware API flows, mapping, and error handling.
No. A dedicated Amazon Cognito connector is not required. Martini can use Cognito's documented HTTPS service APIs, AWS authentication methods, OAuth 2.0/OIDC endpoints, JWTs, and selected Lambda or AWS event mechanisms.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Amazon Cognito. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from AWS, cloud infrastructure, or other third-party systems based on subscription, API usage, and deployment model.
Use Cognito service APIs for administrative operations such as managing Users, Groups, clients, and identity resources. Use OAuth 2.0/OIDC and JWTs for application authentication and protected API access. Use Lambda triggers or AWS event routing only for supported event scenarios, and use scheduled paginated reconciliation when complete synchronization is required.
Cognito does not provide a general-purpose webhook for every User pool operation. It supports selected Lambda triggers and AWS event integrations. A Lambda function or another AWS intermediary can relay supported events to a Martini API, while scheduled reconciliation can cover changes that are not represented by those events.
Martini can receive source-system changes, validate and map attributes, call Cognito service operations, assign Groups, and store stable Cognito identifiers in the source system. For broader reconciliation, a scheduled workflow reads paginated Users and related Group membership, compares them with a source of truth, and applies controlled changes.
Martini can distinguish validation, authorization, conflict, not-found, throttling, and temporary AWS service errors. Workflows can use bounded retries with backoff for transient failures, avoid retrying permanent failures, use stable identifiers and lookup-before-create logic for idempotency, and retain correlation details for monitoring and reconciliation.
Related Martini documentation
Martini APIs
Workflows
Integrate Amazon Cognito with Martini
Use Martini to connect Amazon Cognito identity workflows with enterprise applications, AWS services, and protected APIs through secure orchestration, mapping, and reconciliation.