Approaches for authenticating external applications in a machine-to-machine scenario

AWS Feed
Approaches for authenticating external applications in a machine-to-machine scenario

Amazon Web Services (AWS) supports multiple authentication mechanisms (AWS Signature v4, OpenID Connect, SAML 2.0, and more), essential in providing secure access to AWS resources. However, in a strictly machine-to machine (m2m) scenario, not all are a good fit. In these cases, a human is not present to provide user credential input. An example of such a scenario is when an on-premises application sends data to an AWS environment, as shown in Figure 1.

This post is designed to help you decide which approach is best to securely connect your applications, either residing on premises or hosted outside of AWS, to your AWS environment when no human interaction comes into play. I will go through the various alternatives available and highlight the pros and cons of each.

Figure 1: Securely connect your external applications to AWS in machine-to-machine scenarios

Determining the best approach

Let’s start by looking at possible authentication mechanisms that AWS supports in the following table. I’ll first identify the AWS service or services where the authentication can be set up—called the AWS front-end service. Then I’ll point out the AWS service that actually handles the authentication with AWS in the background—called the AWS backend service. I will also assess each mechanism based on use case.

Notes

• Amazon Cognito as an identity provider is a good fit only when a human end user is involved in the authentication process, for example for authenticating a user on a mobile app or a web application.
• The complete list of AWS services that support Microsoft Active Directory as a source for authentication depends on the specific configuration used on AWS to establish connection with your Active Directory. When using AD Connector, essentially an Active Directory proxy, use this list of services. When using AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD), use this list.

I’ll now review each of these alternatives and also evaluate two additional characteristics on a 5-grade scale (from very low to very high) for each authentication mechanism:

• Complexity: How easy is it to implement the authentication mechanism?
• Convenience: How easy is it to use the authentication mechanism on an ongoing basis?

As you’ll see, not all of the mechanisms are necessarily a good fit for a machine-to-machine scenario. Our focus here is on authentication of external applications, but not authentication of servers or other computers or Internet of Things (IoT) devices, which has already been documented extensively.

Active Directory–based authentication is available through either AWS SSO or a limited set of AWS services and is meant in both cases to provide end users with access to AWS accounts and business applications. Active Directory–based authentication is also used broadly to authenticate devices such as Windows or Linux computers on a network. However, it isn’t used for authenticating applications with AWS. For that reason, I’ll exclude it from further scrutiny in this article.

Let’s look at the remaining authentication mechanisms one by one, with their respective pros and cons.

AWS Signature v4

The purpose of AWS Signature v4 is to authenticate incoming HTTP(S) requests to AWS services APIs. The AWS Signature v4 process is explained in detail in the documentation for the AWS APIs but, in a nutshell, the caller computes a signature using their credentials and then adds it to the header of the HTTP(S) request. On the other end, AWS accepts the request only if the provided signature is valid.

Figure 2: AWS Signature v4 authentication

Native to AWS, low in complexity and highly convenient, AWS Signature v4 is the natural choice for machine-to-machine authentication scenarios with AWS. It is used behind the scenes by the AWS Command Line Interface (AWS CLI) and the AWS SDKs.

Pros

• AWS Signature v4 is very convenient: the signature is built in the SDKs provided by AWS and is automatically computed on the caller’s behalf. If you prefer not to use an SDK, the signature process is a simple computation that can be implemented in any programming language.
• There are fewer credentials to manage. No need to manage tedious digital certificates or even long-lived AWS credentials, because the AWS Signature v4 process supports temporary AWS credentials.
• There is no need to interact with a third-party identity provider: once the request is signed, you’re good to go, provided that the signature is valid.

Cons

• If you prefer not to store long-lived AWS credentials for your on-premises applications, you must first perform authentication through a third-party identity provider to obtain temporary AWS credentials. This would require using either OpenID Connect or SAML, in addition to AWS Signature v4.

Mutual TLS

Mutual TLS, more specifically the mutual authentication mechanism of the Transport Layer Security (TLS) Protocol, allows the authentication of both ends—the client and the server sides—of a communication channel. By default, the server side of the TLS channel is always authenticated. With mutual TLS, the clients must also present a valid X.509 certificate for their identity to be verified.

Amazon API Gateway has recently announced native support for mutual TLS authentication (see this blog post for more details on the new feature). You can enable mutual TLS authentication on custom domains to authenticate your regional REST and HTTP APIs (except for private or edge APIs, for which the new feature is not supported at the time of this writing).

Figure 3: Mutual TLS authentication

Mutual TLS can be both time-consuming and complicated to set up, but it is a widespread authentication mechanism.

Pros

• Mutual TLS is widespread for IoT and business-to-business applications

Cons

• You need to manage the digital certificates and their lifecycles. This can add significant burden and complexity to your IT operations.
• You also need, at an application level, to pay special care to revoked certificates to reduce the risk of misuse. Since API Gateway doesn’t automatically verify if a client certificate has been revoked, you have to implement your own logic to do so, such as by using a Lambda authorizer.

OpenID Connect

OpenID Connect (OIDC), specifically OIDC 1.0, is a standard built on top of the OAuth 2.0 authorization framework to provide authentication for mobile and web-based applications. OIDC can be used to delegate authentication to a third-party identity provider, such as Amazon Cognito or any identity provider supporting that standard, and to gain access to AWS by presenting the token that was obtained from the identity provider. AWS then validates the token with the identity provider and, upon success, it provides a set of AWS temporary credentials to the requesting party. The whole process is described in detail in the AWS Identity and Access Management documentation.

Figure 4: OIDC authentication

OIDC can be complex to put in place, but it’s a widespread authentication mechanism, especially for mobile and web applications and microservices architecture, including machine-to-machine scenarios.

Pros

• With OIDC, you not only avoid storing long-lived AWS credentials for your on-premises applications, but you can also use an existing on-premises directory, such as Active Directory, as an identity provider.
• OIDC doesn’t require a dedicated, pre-existing configuration to be in place in your AWS environment. More specifically, a trust relationship isn’t needed between your preferred identity provider and AWS.
• Last but not least, OIDC uses REST/JSON message flows over HTTP, which makes it a particularly good fit (compared to SAML) for application developers today.

Cons

• Using OIDC with AWS requires a third-party identity provider for your on-premises environment.
• You need to manage the OAuth 2.0 tokens, such as access tokens and refresh tokens, and their lifecycles. This can add significant burden and complexity to your IT operations.

SAML

SAML 2.0 is an open standard for exchanging identity and security information between applications and service providers. SAML can be used to delegate authentication to a third-party identity provider, such as an Active Directory environment that is running on premises, and to gain access to AWS by providing a valid SAML assertion. (See About SAML 2.0-based federation to learn how to configure your AWS environment to leverage SAML 2.0.)

IAM validates the SAML assertion with your identity provider and, upon success, provides a set of AWS temporary credentials to the requesting party. The whole process is described in the IAM documentation.

Figure 5: SAML authentication

SAML can be complex to put in place, but it’s a versatile authentication mechanism that can fit a lot of different use cases, including machine-to-machine scenarios.

Pros

• With SAML, you not only avoid storing long-lived AWS credentials for your on-premises applications, but you can also use an existing on-premises directory, such as Active Directory, as an identity provider.
• SAML doesn’t prescribe any particular technology or protocol by which the authentication should take place. The developer has total freedom to employ whichever is more convenient or makes more sense: key-based (such as X.509 certificates), ticket-based (such as Kerberos), or any other applicable mechanism.
• SAML is also a good fit when protocol bindings other than HTTP are needed.

Cons

• Using SAML with AWS requires a third-party identity provider for your on-premises environment.
• SAML also requires a trust to be established between your identity provider and your AWS environment, which adds more complexity to the process.
• Because SAML is XML-based, it isn’t as concise or nimble as AWS Signature v4 or OIDC, for example.
• You need to manage the SAML assertions and their lifecycles. This can add significant burden and complexity to your IT operations.

Kerberos

Initially developed by MIT, Kerberos v5 is an IETF standard protocol that enables client/server authentication on an unprotected network. It isn’t supported out-of-the-box by AWS, but you can use an identity provider, such as Active Directory, to exchange the Kerberos ticket provided to your application for either an OIDC/OAuth token or a SAML assertion that can be validated by AWS.

Figure 6: Kerberos authentication (through SAML or OIDC)

Kerberos is highly complex to set up, but it can make sense in cases where you already have an on-premises environment with Kerberos authentication in place.

Pros

• With Kerberos, you not only avoid storing long-lived AWS credentials for your on-premises applications, but you can also use an existing on-premises directory, such as Active Directory, as an identity provider.

Cons

• Using Kerberos with AWS requires the Kerberos ticket to be converted into something that can be accepted by AWS. Therefore, it requires you to use either the OIDC or SAML authentication mechanisms, as described previously.

Conclusion

Now I’ll collect and summarize this discussion in the following table, with the pros and cons of each approach.

AWS Signature v4 is the most convenient and least complex mechanism of all, but as for every situation, it’s important to start from your own requirements and context before making a choice. Additional factors may influence your choice, such as the structure or the culture of your organization, or the resources available for your project. Keeping the discussion focused on simple factors on purpose, I’ve come up with the following actionable decision helper.

Use AWS Signature v4 when:

• You have access to AWS credentials (temporary or long-lived)
• You want to call AWS services directly through their APIs

Use mutual TLS when:

• The cost and effort of maintaining digital certificates is acceptable for your organization
• Your organization already has a process in place to maintain digital certificates
• You plan to call AWS services indirectly through custom-built APIs

Use OpenID Connect when:

• You need or want to procure temporary AWS credentials by using a REST-based mechanism
• You want to call AWS services directly through their APIs

Use SAML when:

• You need to procure temporary AWS credentials
• You already have a SAML-based authentication process in place
• You want to call AWS services directly through their APIs

Use Kerberos when:

• You already have a Kerberos-based authentication process in place
• None of the previously mentioned mechanisms can be used for your use case

I hope this post helps you find your way among the various alternatives that AWS offers to securely connect your external applications to your AWS environment, and to select the most appropriate mechanism for your specific use case. I look forward to your feedback.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on one of the AWS Developer forums or contact AWS Support.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.