Skip to content

Best Practice for Third-Party API Access Using Cognito M2M Authentication

0

Hello,

We currently use Cognito User Pools for traditional web application authentication (username/password flows) and considering using Cognito's Client Credentials (M2M) flow to provide external companies access to our APIs, but we want to confirm if this is an appropriate use case:

Current understanding:

  • M2M (Client Credentials) flow is designed for machine-to-machine communication
  • We're planning to use it for external companies to access our APIs
  • Each external company would get their own client credentials (separate app clients)

Key question:

  • Is using Cognito's M2M authentication appropriate for external company access, or is it intended only for internal service-to-service communication within our own organization?
  • Also is it advisable to share the token endpoints (i.e my-domain/auth.us-east-2.amazoncognito.com/oauth2/token) to external parties or provide some sort of proxy to that?
2 Answers
0

Based on the information provided, the implementation approach for external API access using Amazon Cognito's Machine-to-Machine (M2M) authentication.

Machine identities can be both internal to your organization and external partners that need to integrate with your workloads.[1]

  • Client Credentials grant type is appropriate for service-to-service authentication
  • App clients can be configured with specific resource access scopes

Best Practices:[2] Use custom domain names for Cognito user pools to:

  • Maintain consistent domain presence
  • Enable implementation changes without partner impact
  • Implement separate app clients per external company
  • Define specific access scopes per client

Endpoint exposure: For partner integrations, you should consider using a custom domain name with Amazon Cognito user pools. This allows you to maintain a consistent domain presence with your partners and provides the ability to change the underlying implementation without impacting your partners.[1]

You can safely share the token endpoint because the endpoint is protected by [3]

  • Client ID and secret validation
  • TLS encryption
  • OAuth 2.0 standard security measures

we recommend to use custom domains:https://auth.yourcompany.com/oauth2/token

For additional information regarding the token issuer endpoint, please refer to the following link: https://docs.aws.amazon.com/cognito/latest/developerguide/token-endpoint.html.

Explore this blog post for a practical example of how to secure your Amazon API Gateway with Amazon Cognito in the context of machine-to-machine (M2M) communication. The full details are available at https://aws.amazon.com/blogs/mt/configuring-machine-to-machine-authentication-with-amazon-cognito-and-amazon-api-gateway-part-1/.

References [1] Machine-to-machine identity management: https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/m2m-identity-management.html [2]Scopes, M2M, and APIs with resource servers https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-define-resource-servers.html [3] The token issuer endpoint: https://docs.aws.amazon.com/cognito/latest/developerguide/token-endpoint.h

AWS
answered 10 months ago
  • thank you! this is really helpful. I have a follow up question. We have an existing web app that uses the Amplify authenticator, how does creating a custom domain affect this?

0

Since the latest query is more specific toward your user pool setup, it would be great if you can raise a support case on AWS account where user pool is located so that our support engineers would be able to investigate further on your use case

AWS
answered 10 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.