To improve the security of HTTP services, you can configure JSON Web Token (JWT) authentication for HTTP triggers in Function Compute. This way, unauthenticated access is denied, and malicious attacks are blocked. Only clients for which a valid JWT is configured can access HTTP services.
Background
Overview
Function Compute allows you to enable JWT authentication for HTTP triggers. JWT is an open standard (RFC: 7519) that defines how to authenticate requests based on tokens. User status information is stored in tokens
provided by clients. Functions or servers do not store tokens. Therefore, JWT authentication is suitable for serverless applications. Function Compute can use the public JSON Web Key Set (JWKS) that is configured for an HTTP trigger to implement JWT authentication on HTTP requests. Function Compute forwards claims
to functions based on the configurations of HTTP triggers. This way, functions can focus on business logic without the need to manually authenticate requests. For more information about the authentication process and basic information about tokens
in JWT, see JWT-based authentication and Introduction to JSON Web Tokens.
JWT authentication process
The preceding figure shows the workflow of JWT authentication for HTTP triggers in Function Compute. In the process, an asymmetric encryption algorithm is used. The following information describes the process details.
The client sends an authentication request to a custom authorization server. In most cases, the username and password of the user are specified in the request.
The custom authorization server reads and verifies information, such as the username and password of the user, in the authentication request. After the request passes authentication, the server uses a private key to generate a standard
token
.The custom authorization server forwards the response that contains the
token
to the client. The client caches thetoken
to an on-premises machine.The client sends a business request that contains the
token
to the HTTP trigger.The HTTP trigger uses the configured public key to verify the
token
in the request.After the token is verified, the request is passed to the protected function.
The protected function processes and responds to the request.
The HTTP trigger forwards the business response to the client.
Prerequisites
A service is created. For more information, see the "Create a service" section of the Manage service topic.
An HTTP function is created. For more information, see the "Create a function" section of the Manage functions topic.
Limits
You can generate and distribute JWTs based on your business requirements. Function Compute authenticates the JWTs by using the public JWKS configured for triggers.
A JSON Web Key (JWK) without
kid
is supported.A token can be read from a
header
,query
(by using the GET method), form (by using the POST method), orcookie
parameter.You can forward
claims
asheaders
,queries
(by using the GET method), forms (by using the POST method), orcookies
to functions.You can configure a JWKS for an HTTP trigger. After you configure a JWKS, the public JWK that is similar to the
kid
parameter in thetoken
is searched and used to verify the signature of the token. You can leave up to onekid
of a JWK empty, or set kid to an empty string.The following table describes the algorithms supported by JWT of Function Compute.
Signature algorithm
alg value
RSASSA-PKCS1-V1_5
RS256, RS384, or RS512
RSASSA-PSS
PS256, PS384, or PS512
Elliptic Curve (ECDSA)
ES256, ES384, or ES512
HMAC
HS256, HS384, or HS512
EdDSA
EdDSA
ImportantThe hash-based message authentication code (HMAC) signature algorithm uses symmetric encryption, which is less secure. We recommend that you use an asymmetric encryption algorithm to ensure security.
When you use an asymmetric encryption algorithm, you need to only include information about public keys in your JWT for security purposes. You do not need to include private keys in your JTW.
We recommend that you use HTTPS to protect sensitive information such as
tokens
in requests to prevent token leaks.
Procedure
Step 1: Configure JWT authentication
Log on to the Function Compute console. In the left-side navigation pane, click Services & Functions.
In the top navigation bar, select a region. On the Services page, click the desired service.
On the Functions page, click the name of the desired function. On the Function Details page that appears, click the Trigger Management (URL) tab.
On the Trigger Management (URL) tab, click Modify in the Actions column of the HTTP trigger.
In the Modify Trigger panel, configure the following parameters and click OK.
Set Authentication Method to JWT Authentication.
Configure JWKS.
To configure JWT authentication for the HTTP trigger, you must provide a valid JWKS. You can manually prepare a JWKS, or search for JSON Web Key generator in a web browser to use an online generator, such as mkjwk.org. If you have a key in the Privacy Enhanced Mail (PEM) format, you can use a tool such as jwx to convert the key to the JWKS format.
In this example, mkjwk.org is used to generate JWKS. On the page for generating JWKS, set Show X.509 to Yes to view the private keys. If you want to use a private key to issue a JWT in your code, keep it secure. You can copy the content of the public key to the keys array of JWKS in the Function Compute console. The following figure shows the details.
Sample code:
{ "keys": [ { "alg": "RS256", "e": "AQAB", "kty": "RSA", "n": "u1LWgoomekdOMfB1lEe96OHehd4XRNCbZRm96RqwOYTTc28Sc_U5wKV2umDzolfoI682ct2BNnRRahYgZPhbOCzHYM6i8sRXjz9Ghx3QHw9zrYACtArwQxrTFiejbfzDPGdPrMQg7T8wjtLtkSyDmCzeXpbIdwmxuLyt_ahLfHelr94kEksMDa42V4Fi5bMW4cCLjlEKzBEHGmFdT8UbLPCvpgsM84JK63e5ifdeI9NdadbC8ZMiR--dFCujT7AgRRyMzxgdn2l-nZJ2ZaYzbLUtAW5_U2kfRVkDNa8d1g__2V5zjU6nfLJ1S2MoXMgRgDPeHpEehZVu2kNaSFvDUQ", "use": "sig" } ] }
In the JWT Token Configuration section, select the read position of the
token
and the name of thetoken
.You can set the Read Position parameter of the
token
to Header, Cookie, Query Parameters, or Form Parameters. If you set the Read Position parameter of thetoken
to Header, you must specify a prefix that you want to remove when Function Compute obtains the token.In the JWT Claim Conversion section, select the position to pass parameters to the function, the original name of the parameter, and the new name of the parameter after the parameter is passed to the function.
You can set the Mapping Parameter Position parameter to Header, Cookie, Query Parameters, or Form Parameters.
Specify the request matching mode.
Match All: All HTTP requests must be verified by using JWT.
Whitelist Mode: HTTP requests that are sent from the paths specified in Whitelist of Request Paths are not verified by using JWT. Other requests are verified by using JWT.
Blacklist Mode: HTTP requests that are sent from the paths specified in Blacklist of Request Paths are verified by using JWT. Other requests are not verified by using JWT.
Whitelist Mode and Blacklist Mode support the following matching modes:
Exact match
A path is matched only if the path is exactly the same as the specified path. For example, if you set the Blacklist of Request Paths parameter to /a, JWT verification is required for requests that are sent from /a. JWT verification is not required for requests that are sent from /a/.
Fuzzy match
You can set the value to a path that is appended with an asterisk wildcard (*). For example, if you set the Blacklist of Request Paths parameter to /login/*, requests that are sent from the paths prefixed with /login/, such as /login/a and /login/b/c/d, are verified by using JWT.
Step 2: Verify JWT configurations of the HTTP trigger
This section describes whether HTTP services can be accessed as expected by using a tool based on the configurations of an HTTP trigger, such as the Internet endpoint, internal endpoint, and token. In this section, Postman is used for debugging and testing.
Use the private key generated in Step 1 to create a JWT.
Use Postman to verify whether an HTTP service is accessible.
On the Trigger Management (URL) tab of the function that you want to manage, obtain the Internet endpoint of the HTTP trigger. Then, enter the endpoint in the address bar on the Postman page.
Configure the parameters of a token in the headers of Postman. The following table describes the configuration of the token.
Parameter
Value
Description
Key
Authentication
The name of the token that you specified in the JWT Token Configuration section.
Value
Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiSm9uIFNub3ciLCJhZG1pbiI6dHJ1ZSwiZXhwIjo0ODI5NTk3NjQxfQ.eRcobbpjAd3OSMxcWbmbicOTLjO2vuLR9F2QZMK4rz1JqfSRHgwQVqNxcfOIO9ckDMNlF_3jtdfCfvXfka-phJZpHmnaQJxmnOA8zA3R4wF4GUQdz5zkt74cK9jLAXpokwrviz2ROehwxTCwa0naRd_N9eFhvTRnP3u7L0xn3ll4iOf8Q4jS0mVLpjyTa5WiBkN5xi9hkFxd__p98Pah_Yf0hVQ2ldGSyTtAMmdM1Bvzad-kdZ_wW0jcctIla9bLnOo-Enr14EsGvziMh_QTZ3HQtJuToSKZ11xkNgaz7an5de6PuF5ISXQzxigpFVIkG765aEDVtEnFkMO0xyPGLg
The header used to read the token. You must leave a space between the prefix to be removed and the token. The header part that excludes the prefix is used as the token.
Click Send to view the returned information of the HTTP service. The following information is returned:
In the returned information,
nametofunction
indicates the name that is passed to the function by Claim.
Use JWT authentication with a custom domain name
The preceding figure shows that a custom domain name processes user requests before an HTTP trigger processes the requests. JWT authentication is performed on the HTTP trigger. This section describes how to use JWT authentication in scenarios in which custom domain names are configured.
Custom domain names with no rewrite policies configured
If routes are configured for a custom domain name with no rewrite policy configured, the paths of the incoming HTTP requests are the paths of the custom domain name.
For example, the following table describes the route rule for the custom domain name www.fc-jwt.com
. The value of the Blacklist of Request Paths parameter in the JWT configuration of the HTTP trigger for the jwt-demo
function is /fc-jwt/auth/*.
Path | Service | Function | Version |
/fc-jwt/* | jwt | jwt-demo | 1 |
If the URL of a request is /fc-jwt/auth/aliyun, the HTTP trigger verifies the HTTP request because the path of the request matches the value that is specified in the Blacklist of Request Paths parameter.
Custom domain names with rewrite policies configured
If routes are configured for the custom domain name with a rewrite policy configured, the paths of the incoming HTTP requests are rewritten URLs. For more information about the rewrite feature for custom domain names, see Configure rewrite policies (in public review).
For example, the following table describes the route rule for the custom domain name www.fc-jwt.com
. In the JWT configurations of the HTTP trigger for the jwt-demo
function, the /fc-jwt/auth/* is specified for the Blacklist of Request Paths parameter, and a wildcard rewrite policy is configured. The match rule is /fc-jwt/*
, and the replacement rule is /$1
.
Path | Service | Function | Version |
/fc-jwt/* | jwt | jwt-demo | 1 |
If the URL of a request is /fc-jwt/auth/aliyun, the rewritten URL is /auth/aliyun. For more information about the wildcard rewrite rules, see Configure rewrite policies (in public review). The HTTP trigger does not verify the request. In this case, the path of the request to the HTTP trigger is /auth/aliyun and does not match the value of the Blacklist of Request Paths parameter.
If you set the Request Path Blacklist parameter to /auth/*, the HTTP trigger performs JWT authentication on the request whose URL is /fc-jwt/auth/aliyun.