M2M apps scoped to organizations
Machine-to-Machine (M2M)
Here are short answers to the most common M2M questions. Click any question to expand the answer.
M2M authentication is for servers, APIs, and automated systems that communicate without user interaction. Unlike user authentication (password, social sign-in, or SSO), M2M uses the OAuth 2.0 client credentials flow: the application authenticates with a client ID and secret to obtain an access token. This pattern is commonly used for microservices, background jobs, and system integrations.
Create a new application in the Kinde dashboard and select “Machine to machine” as the app type. Kinde issues a client ID and client secret. M2M applications do not require callback URLs because there is no user redirect flow. Assign API access and scopes based on least privilege, then expand only when required.
Do not store M2M credentials in source code or version control. Use environment variables and a secrets manager (for example AWS Secrets Manager, Azure Key Vault, or Google Secret Manager), or your platform secure configuration system. Rotate client secrets regularly, especially after potential exposure. Use separate M2M applications per environment (development, staging, production) to reduce blast radius.
Apply least privilege by creating separate M2M applications for distinct services or workflows. This limits impact if one credential is compromised and improves auditability because API calls map to a specific integration.
M2M access tokens expire (usually after an hour), so your application needs to handle token refresh gracefully. Most Kinde SDKs handle this automatically, but if you’re doing it manually, implement retry logic that gets a fresh token when you receive 401 responses. Cache tokens in memory and refresh proactively before expiry. For high-traffic systems, use a short-lived, in-memory cache per host/process to reduce token requests. Do not share tokens across services or persist them.
M2M uses the client credentials flow only; there are no refresh tokens. You obtain access tokens by authenticating with your client ID and client secret. When an access token expires, request a new one using the same client credentials. Do not use or expect a refresh token.
About machine-to-machine applications | Authenticate with M2M
Scope requirements depend on operations. For user management, common scopes include read:users and write:users; for organization workflows, include read:organizations and write:organizations; billing integrations require billing-related scopes. Start with minimal scopes and expand as needed based on endpoint requirements.
Respect rate limits and implement exponential backoff on throttled responses. Batch operations where possible, use bulk endpoints for high-volume workflows, and cache low-change data to reduce repeated calls. If limits are still reached after optimization, contact Kinde support with traffic details.
Always check HTTP status codes before processing response bodies. Parse JSON defensively, including missing or optional fields. Implement pagination for list endpoints. Log response metadata for debugging, but never log credentials or access tokens. Use idempotent writes where possible so retries do not create duplicate side effects. Troubleshoot M2M token errors
Use separate M2M applications per environment to isolate test and production data. Create dedicated test organizations and users. Configure CI/CD to use non-production credentials. Mock API responses in unit tests, and validate failure handling for timeouts, errors, and malformed responses.
Each microservice should have its own M2M application with only the permissions it needs - this follows the principle of least privilege and makes security auditing much easier. Consider creating a shared authentication service that handles token management for all your microservices, or use a service mesh that can inject tokens automatically. Don’t pass M2M tokens between services - each service should authenticate directly with Kinde. This prevents token leakage and makes it easier to track which service is making which API calls.
Use webhooks for near-real-time change notifications, then call M2M APIs to fetch updated records as needed. Avoid maintaining a full mirror unless required; instead, cache frequently accessed fields and refresh authoritative data for critical operations. Use retry logic and eventual-consistency patterns where acceptable.
M2M is well suited to automated organization provisioning. You can create organizations, assign initial users and permissions, and apply billing configuration through the Management API. Use stable naming conventions and store Kinde organization IDs in your internal records for reliable mapping.
Set up M2M workflows for user creation, organization assignment, and initial permission setup based on business rules. Trigger these from webhooks, scheduled jobs, or upstream system events. Include handling for duplicates, quota constraints, and reconciliation.
Start with credential validation for the target environment. M2M credentials are environment-specific, so development credentials do not work in production. Use error codes to isolate root causes: invalid_client typically indicates credential issues, while insufficient_scope indicates missing permissions. If failures begin after a period of success, verify credential rotation and scope changes.
Implement logging for request latency, error rates, and token refresh behavior. Use correlation IDs to trace cross-service calls. Configure alerts for authentication failures and abnormal traffic patterns. Kinde dashboard metrics are helpful, but production systems should also use dedicated application monitoring.
First, optimize request patterns by removing unnecessary calls, batching workloads, and caching low-change data. Ensure pagination is implemented for large datasets. If higher limits are still required, contact Kinde support with your use case, expected traffic, and optimization steps already taken.
Design resilience for intermittent network and service failures. Use exponential backoff with jitter, reasonable timeouts, and circuit breakers for critical paths. Log enough context for diagnosis without excessive retry noise. For non-critical tasks, use queues so retries do not block primary workflows.
Use M2M automation for lifecycle tasks such as account provisioning, deactivation, and permission updates. Trigger workflows via webhooks, then apply changes through M2M API calls. For enterprise onboarding, you can automate organization setup and authentication configuration. Maintain audit logs for compliance and traceability.
Serverless functions are a good fit for M2M because they can request short-lived tokens per execution without long-term token storage. For background jobs, use token caching with explicit expiration handling. Account for cold-start latency where authentication response time is critical.
Design synchronization jobs to be idempotent so repeated execution does not create duplicates. Query incremental changes through the Management API, then apply updates downstream. Implement retry logic and failure handling. For near-real-time requirements, use queues or event streams. Validate sync behavior with high-volume test data before production rollout.
M2M applications support automated compliance workflows, including access reporting, permission-audit checks, and automated revocation for inactive users. Use the Management API to query relevant activity and organization changes, then format outputs for compliance processes. Schedule policy checks and maintain a complete operation audit trail.