Using Custom Authorizer Context with Lambda Proxy Integration

The missing documentation on how to get the user context from a custom authorizer when using lambda proxy integration.

“beefeaters” (CC BY 2.0) by RituAshrafi

AWS is an interesting beast. As a company they seemed to have mastered the art of balancing price and delivery. Which is a polite way of saying; ‘developing anything for AWS is often frustrating, but never so bad that you could justify paying more elsewhere.’ And one of the places that AWS likes to lead the naive developer astray is their documentation.

If you’ve never used them- AWS let’s you write ‘Custom Authorizers’ (or Authorisers, if, like me, you’re British and have some sort of vendetta against the letter ‘z’). When using API Gateway to provide a RESTful API interface to your tribe of backing lambda functions, a Custom Authorizer is a special lambda that is called first and either denies or invokes the backing functionality.

The world’s shortest Custom Authorizer in the world can be written as so:

Note that to ‘authorize’ you must return an IAM policy (for some terrible reason) for a pseudo-user/role (it’s helpful, but not required, for principleId to be related to the requesting user) that has the right to invoke the function it’s authorizing.

However, most usefully, you can also add context to your response. context is a flat (e.g. no arrays or nested objects) JSON object which forms a key/value store of information about the authenticated user. Things like account-id come to mind- but I’m sure there’s a lot of fun things you can do, like a bitflag for finer-grain permissions…

Where the documentation falls down, however, is that it only gives you details on how to access these variables by injecting them into the request object using body mapping templates. Not only is this just generally awful to do in AWS, but, seemingly, the de facto integration with lambda functions is the lambda proxy method.

For those of you not already in the know, the lambda proxy integration is just an annoying way of saying ‘we’ll pass you the whole event, and you can work out what the hell you want to do about it’. It’s much prefered, as it gives you so much more insight into the body and headers that your method was called with.

If you call your function through a custom authoriser, you’ll find the context you passed in the event.requestContext.authorizer object.

Which is a useful piece of not-very-well-documented information. Armed with; you can now write this incredibly ground-breaking lambda function behind your authoriser:

What a world we live in.