Is it safe to store public keys/policies in a node.js constant in Lambda

I am writing a AWS lambda Authorizer in node.js. We are required to call Azure AD API to fetch the public keys/security policies to validate the incoming the Access Token.

However, to optimize the performance, I decided to store the public keys/security policies in node.js as a constant (this will be active until the Lambda is running or TTL of the keys expire).

Question : Is it safe from a security perspective ? I want to avoid "caching" it in DynamoDB as calls to DynamoDB would also incur additional milliseconds. Ours is a very high traffic application and we would like to save any millisecond possible for optimal performance. Also, any best practice is also higly appreciated

Typically, you should not hard-code things like that in your code. Even though it is not a security problem, it is making maintenance harder.

For example: when the key is "rotated" or the policy changed and you had it hard-coded in your Lambda, you would need to update your code and do another deployment. This is often causing issues, because the developer forgot about this etc. causing issues because your authorizer does not work anymore. If the Lambda loads the information from an external service like S3, SSM or directly Azure AD, you don't need another deployment. In theory, it should sort itself out depending on which service you use and how you manage your keys etc.

I think the best way is to load the key from an external service during the initialisation phase of the Lambda. That means when it is "booted" for the first time and then cache that value for the duration of the Lambdas lifetime (a few minutes to a few hours).

You could for example load the public keys and policies either directly from Azure, from S3 or SSM Parameter Store.

The following code uses the AWS SDK NodeJS v3, which is not bundled with the Lambda Runtime. You can use v2 of the SDK as well.

const { SSMClient, GetParameterCommand } = require("@aws-sdk/client-ssm");

// This only happens once, when the Lambda is started for the first time:
const init = async () => {
    const config = {}

    try {
        // use whatever 'paramName' you defined, when you created the SSM parameter
        const paramName = "/azure/publickey"
        const command = new GetParameterCommand({Name: paramName});
        const ssm = new SSMClient();
        const data = await ssm.send(command);
        config["publickey"] = data.Parameter.Value;
    } catch (error) {
        return Promise.reject(new Error("unable to read SSM parameter '"+ paramName + "'."));
    }

    return new Promise((resolve, reject) => {
        resolve(config);
        reject(new Error("unable to create configuration. Unknown error."));
    });
};

const initPromise = init();

exports.handler = async (event) => {
    const config = await initPromise;

    console.log("My public key '%s'", config.key);

    return "Hello World";
};

The most important point of this code is the init "function", which is only run on once, creating a "config" which should contain your AWS SDK clients and all the configuration you need in your code. This way, you don't have to get the policy for every request that the Lambda is processing etc.