Feature Request (API): Support API authorizers and passing user information to the closure

[thantos]

Right now, we create an unauthorized api endpoint with no customization.

We pass through the APIg request (which isn't a great contract if we are going to support other api gateway solutions).

1. Support a provided authorizer (or an authorizer method? api.authorizer(() => ...))
2. Transform the APIg request to pull out important information like authorizer output, headers, etc.

Q:

1. Would you want an unique authorizer/auth type per api?
2. What auth types? Custom, IAM, etc

[winklerj]

1. Yes, each API could have a different auth type. Systems that would be sending data have constraints on what type of auth they can send
2. I have use cases for custom (ex. HMAC), JWT, and IAM

[thantos]

From discord: https://discord.com/channels/985291961885949973/1053066041149886596/1068215231647600770

@yehudacohen

let's respond to questions in reverse since I think it makes more sense:

_3. building an app where users should only be able to mutate or view their own data. I need endpoints secure to ensure users aren't able to access each other's data. _2. I kind of feel like this should be abstracted by the framework and come out of the box so users don't need to understand implementation details. With that said framework should allow extensibility and swapping out the default implementation. _1. Would like the ability to set globally and override per route.

@thantos

_3. Cool, makes sense

_2. Alright, I think I would break this into two issue, 1) apis supporting authorization and gracefully sending it to the handler, and 2) a module that bringing in a light weight, opinionated user pool and auth that plays well with the handlers, is type safe, etc. A developer of a microservice likely doesn't want user level authorization, they want service to service auth (IAM or similar) A developer of a frontend with eventual as the backend would want exactly what you asked for (cognito, google, facebook, auth0, OAuth, OIDC, etc).

_1. Makes sense, we are working on the routing and bundling logic that would allow this (right now all of the APIs go to the same lambda).