AWS Lambda - manage OAuth token

nmunro
Participant III

Hello,

I am exploring the use of AWS Lambda functions as a client to Apigee API proxies and I am looking for a good architecture for requesting and re-using OAuth tokens generated from Apigee.

The Lambda function that initiates the process is itself initiated from a request to Apigee (currently the Apigee API will used a node.js target that triggers Lambda via SNS)

The proposals suggested by the team so far include:

  1. Lambda functions calling apigee also request a token from Apigee (on each execution)
  2. (Associated) Lambda functions share a token that is temporarily stored in DynamoDb, where each function contains the logic to manage the token and request a new token if it is found to be expired
  3. The token request and management is moved to a separate Lambda function to be invoked by the other functions as necessary (with something like DynamoDb as a temporary token store)
  4. The token is passed with the original SNS trigger (or a direct Lambda call from Apigee node.js) and can therefore be shared among subscribing functions - Lambda has no token requests or management

At the moment we're settling on 1. mostly so that we can get started and experiment but my concern is that as we add more functions, and possibly see multiple instances of a function at a time, we'll end up with too many (unnecessary) token requests.

What is a good pattern for managing tokens across Lambda functions?

Thanks

1 2 3,203
2 REPLIES 2

I don't like #1 for the reason you cited, Neil.

You ideally want to be able to cache tokens on the client side for the life of the token.

I don't know enough about Lambda to suggest the best ways to store the live tokens.

If Apigee Edge were the client that needed to obtain and cache tokens, then I'd suggest using the ServiceCallout policy wrapped with a LookupCache and PopulateCache policy. Pretty simple. In fact I just implemented this pattern for integration into Stackdriver... Apigee Edge acting as a client of Stackdriver. There was just one additional twist: the request-for-token required a client-generated JWT. But we can do that in Apigee Edge pretty easily, too.

Maybe it's more difficult in Lambda... I dunno. Maybe you should ask on the AWS forums?

Does DynamoDb have an "expiry" option for data?

@Dino, Thanks for your reply.

I agree that it's really a Lambda architecture question.

I'm now implementing this differently using a command (-style) pattern:

A "command" lambda function subscribes to the SNS message and gets the data we need (in this case from SQS) and calls our Identity API for a token.

This command function then invokes a parallel cascade of a lambda function that posts back to our target via our apigee proxy. The command function passes the token to each instance of the posting lambda function that it invokes.

I still have the feeling that it can be simplified again but I think we have a better solution than before.