Serverless computing is being rapidly adopted by organizations, as a way to rapidly deploy software without managing the underlying infrastructure. While serverless has compelling benefits in terms of ease of maintenance and lower cost, it also raises new complexities. One of the issues developers need to address is how to authenticate users, and integrated systems, in a serverless architecture.
Want more tech news? Subscribe to ComputingEdge Newsletter Today!
Serverless authentication has several aspects:
- Allowing users to sign up with an enterprise identity provider such as Active Directory, or third-party identity providers like Google or Facebook.
- Authorizing access once users are authenticated.
- Using tokens to securely exchange data between services—this is typically done using JSON Web Tokens (JWT).
- Enabling direct access to services from the front end via delegation tokens.
- Enabling single sign-on using protocols like OAuth or SAML.
In this article, I’ll show how authentication and authorization work in three popular serverless runtimes—AWS Lambda, Azure Functions, and Google Cloud Functions.
AWS Lambda Authentication and Authorization
Lambda is an event-driven, cloud-based service. It lets developers program functions in keeping with a pay-per-use structure. You don’t have to provision compute storage or resources to support these functions.
A Lambda authorizer is a type of API Gateway. It employs Lambda functions to manage access to APIs.
Lambda authorizers can help you implement a customized authorization approach that makes use of bearer tokens such as SAML or OAuth. It might also assist you with the implementation of a custom authorization process that employs request parameters to verify the identity of any caller.
After a client puts a request to an API method, the Lambda authorizer is called by the API Gateway. The authorizes uses the caller’s identity as an input and responds with an output of an Identity Access Management (IAM) policy.
The following are two forms of Lambda authorizers:
- A token-based Lambda authorizer—called a token authorizer. It gets the caller identity in a bearer token, for example, a JSON Web Token or an OAuth token.
- An authorizer based on request parameters—called a request authorizer. It gets the caller identity through a combination of query string parameters, headers, stage variables, and context variables.
This diagram shows the authorization workflow of Lambda authorizers:
1. An API Gateway is called by the client, providing request parameters or a bearer token.
2. The API Gateway verifies if the Lambda authorizer is appropriate. If it is configured, the Lambda function is called by the API Gateway.
3. The caller is authenticated by the Lambda function as follows:
- Calling an OAuth provider to request an OAuth token
- Calling a SAML provider to request an assertion
- Producing an IAM policy founded on a request parameter value
- Accessing credentials via a database
4. If the call is successful, the Lambda function provides access and returns an output that contains at least a main identifier and an access management policy.
5. API Gateway checks the policy:
- If the policy forbids access, the API provides an appropriate HTTP status code.
- If the policy permits access, API Gateway carries out the method. If, in the authorizer settings, caching is enabled, API Gateway caches the policy so a Lambda authorizer function needn’t be used again.
Azure Functions Authentication and Authorization
Azure Functions is a serverless service hosted on the Azure public cloud, often used to optimize Azure compute costs by switching from under-utilized VMs to lightweight serverless functions. It is designed to simplify and accelerate application development. Here is how Azure Functions handles authentication.
Require HTTPS
Azure Functions lets you connect clients to function endpoints through HTTP or HTTPS. HTTPS employs the Transport Layer Security (TLS) protocol to secure connections through encryption and authentication. Ideally, you should favor HTTPs over HTTP and require the latest TLS version (as opposed to the outdated SSL) when requiring HTTPS.
Access Keys
Azure Functions enables you to use keys to secure access to endpoints with HTTP functions throughout development. If the access level of an HTTP function is not set to anonymous, the requests must contain API access keys.
Here are two scopes for access keys at the function level:
-
- Function—keys that only apply to specified functions. You can use them as API keys, to enable access to these functions.
-
- Host—keys that apply to all functions in the application. You can use them as API keys, to enable access to any function.
All keys are named for reference. The default key is named “default”, both at the function and the host level. When two keys get the same name, the function key is preferred.
Authentication and Authorization
To secure function endpoints, you need to implement positive authentication of any clients attempting to access functions. This allows you to make authorization-related decisions based on identity.
Enable app service authentication and authorization
To authenticate clients, you can use the App Service platform in combination with Azure Active Directory (AAD), as well as other identity providers. This strategy can help you customize the authorization rules for functions, and also enables you to utilize the user information in the function code.
Azure API Management (APIM)
APIM offers several security options for incoming API requests. It lets you configure your function application to only accept requests from the APIM instance’s IP address.
Organize functions according to privileges
Credentials stored in the application’s settings, including connection strings, give the same privileges to every function in the function application related to a specific resource.
You should minimize the number of functions that have access to certain credentials. To do this, move functions that do not use certain credentials to another, separate function app.
Google Cloud Functions Authentication and Authorization
Google Cloud Functions is an event-driven serverless service. It lets you create and implement programmatic functions in Google’s public cloud. There is no need to provision any underlying cloud infrastructure, such as storage and servers.
Here is how you can control access to Cloud Functions:
-
- Authentication—when an entity presents credentials, evaluate the information to validate identity.
-
- Authorization—after the entity is successfully authenticated, you can let it access resources according to the permissions the identity has been granted.
Cloud Functions lets you use Identity and Access Management (IAM) as well as OAuth 2.0.
Using Identity and Access Management
IAM lets you control access in Cloud Functions using the following types of identities:
- Service accounts—accounts that represent the identity of non-person entities, such as functions, applications, or virtual machines (VMs). They let you authenticate non-person entities and grant them certain permissions. For example, to call a certain API.
- User accounts—accounts represent people. A user account can represent an individual Google account holder or serve as a part of a Google-controlled entity, such as a Google Group.
You can grant appropriate roles to a requesting identity during setup. Roles define what permissions an identity gets within the context of a resource.
Using OAuth 2.0
OAuth 2.0 provides an open standard used for authorization purposes, which can serve as an alternative to IAM when appropriate and needed. Note that while IAM bases permissions according to roles, OAuth 2.0 bases permissions according to a scope value.
You can use Google Cloud Console to create an OAuth 2.0 client ID for your client application. The new OAuth 2.0 client ID serves as a credential that the client application sends to the Google Authorization Server, which then provides an access token that provides access to a resource.
Network-Based Access Control
You can limit access by defining network settings for each function. You can use this option to fine-tune control over the network egress and ingress from and to your functions.
Isolation and Sandboxing
Function instances are internally isolated from each other by the gVisor sandboxing platform. By default, a function cannot access the operating environments of other functions.
Conclusion
In this article, I covered authentication and authorization capabilities of three leading serverless runtimes:
- AWS Lambda—using API Gateway, Lambda Autorizers, and a Lambda function that obtains an OAuth access token, gets a SAML assertion, or similar.
- Azure Functions—using function access keys and specific authentication features in App Server and Azure API Management.
- Google Cloud Functions—using Google identity and access management (IAM), OAuth 2.0, and network-based access control.
I hope this will be of help as you build authentication and authorization into your next serverless project.
