We’re designing security architecture for our ERP integration APIs and evaluating different authentication/authorization patterns. Our environment has three types of API consumers: internal microservices, external partner ERP systems, and third-party analytics tools.
The debate is between OAuth2 with delegated access (more flexible, industry standard), API keys managed through API Gateway (simpler, easier for ERP teams), and IAM roles with SigV4 signing (AWS-native, strong security). Each has tradeoffs in terms of implementation complexity, security posture, and operational overhead.
What security patterns have worked well for others? How do you handle different trust levels for different consumer types? Any lessons learned on key rotation, token expiration, or credential management?
API key management becomes a nightmare at scale if you don’t automate it. We have 30+ external ERP systems, and manual key rotation was causing constant breakages. We built a self-service portal where partners can generate and rotate their own keys, with automated email notifications 30 days before expiration. Keys are stored in Secrets Manager with automatic rotation enabled. This reduced our operational overhead by 80% and improved security posture since keys actually get rotated now instead of living forever.
We use different patterns for different consumer types. Internal microservices use IAM roles with SigV4 - it’s the most secure option and integrates natively with AWS. External partners use API keys through API Gateway usage plans, which gives us throttling control and easy key rotation. For third-party tools that need delegated access (accessing data on behalf of specific users), we implemented OAuth2 with Cognito. The hybrid approach adds complexity but matches security requirements to trust levels.
From a compliance perspective, make sure you’re logging all authentication attempts (successes and failures) and implementing rate limiting to prevent brute force attacks. API Gateway usage plans help with throttling, but you should also implement account lockout after repeated failed auth attempts. For sensitive ERP data (financials, PII), consider mutual TLS in addition to API keys or OAuth2. We require mTLS for all production integrations handling financial data - it adds setup complexity but provides strong client authentication.
Thank you all for the detailed perspectives. Here’s our final security architecture based on this discussion:
OAuth2 Delegated Access: Implementing OAuth2 via Cognito for third-party analytics tools that need user-delegated access. Using authorization code flow with PKCE for web apps and client credentials flow for machine-to-machine integrations. Access tokens expire in 1 hour, refresh tokens in 30 days. We’re defining granular scopes (orders:read, inventory:write, financials:read) to implement least-privilege access. This gives us the flexibility to grant different permission levels to different consumers.
API Key Management: For external partner ERP systems, using API Gateway API keys with usage plans. We’ve built a self-service portal (inspired by erp_integration_lead’s approach) where partners can generate, rotate, and revoke their own keys. Keys are stored in Secrets Manager with 90-day rotation policy. Usage plans provide throttling (1000 requests/sec per partner) and quota limits (10M requests/month). This balances ease of use for ERP teams with operational security.
IAM Role-Based Permissions: For internal microservices and AWS-native consumers, using IAM roles with SigV4 signing. This is the most secure option - no credentials to manage, automatic rotation, and full CloudTrail audit logging. We’ve created resource-based policies on API Gateway that require specific IAM role ARNs. For partners with AWS accounts, we offer cross-account IAM role assumption as an alternative to API keys - it’s more secure and eliminates key management overhead.
Additional security layers:
- Mutual TLS required for all production APIs handling financial data or PII
- API Gateway resource policies restricting access to known IP ranges for partner integrations
- CloudWatch alarms for failed authentication attempts (>10 failures/minute triggers incident response)
- WAF rules protecting against common attacks (SQL injection, XSS) at the API Gateway edge
- Automated key rotation testing in staging environment before production rollout
- Quarterly access reviews to revoke unused API keys and OAuth2 clients
The multi-pattern approach matches security controls to trust levels and consumer capabilities. Internal services get the strongest security (IAM roles), partners get operationally simple API keys with good security, and third-party tools get OAuth2 for delegated access. This architecture passed our security review and compliance audit.
IAM role-based permissions are underutilized for API security. If your consumers are AWS services or can assume IAM roles, this is the gold standard. You get fine-grained permissions via IAM policies, automatic credential rotation, and CloudTrail audit logging. We use cross-account IAM roles for partner integrations where the partner has an AWS account. They assume a role in our account with specific API Gateway resource policies. No API keys to manage, no tokens to expire. The downside is it only works when consumers can use AWS SDK for SigV4 signing.
OAuth2 delegated access is essential if you’re building a platform where third parties access data on behalf of specific users or tenants. We use the client credentials flow for machine-to-machine (ERP to API) and authorization code flow for user-delegated access. Cognito handles the OAuth2 server duties. The key benefit is fine-grained scopes - you can grant read-only access to orders but not financials, for example. Token expiration is set to 1 hour for access tokens, 30 days for refresh tokens. This balances security with usability.