In a micro-service architecture where the bearer token is passed to each service, it's much more efficent for each micro-service to validate the token locally than calling a centralized authorization service.
Point "x-tokenInfoUrl" (or a different attribute) to a local function that will validate the bearer token locally.
"x-tokenInfoUrl" only accepts URLs.
@horomena we (at Zalando) actually support local token validation via HTTP, e.g. by running https://github.com/zalando/planb-tokeninfo as a sidecar in your Kubernetes pod :smirk:
But in general it sounds like a good idea and it's related to #124.
Would it be a solution to add something like x-tokenInfoFunc in which we pass a function similar to the operationId?
We'd then adapt the security_decorator to check whether any of the two is present and return the respective partial. Where x-tokenInfoUrl returns the implementation which checks the remote endpoint and x-tokenInfoFunc returns the implementation which calls a local function.
Yep, that would be great
@MaicoTimmerman sounds good, would you be willing to implement this? :smile:
We can close this issue.
Closing as it was released here: https://github.com/zalando/connexion/releases/tag/1.3
Most helpful comment
Would it be a solution to add something like
x-tokenInfoFuncin which we pass a function similar to theoperationId?We'd then adapt the security_decorator to check whether any of the two is present and return the respective partial. Where
x-tokenInfoUrlreturns the implementation which checks the remote endpoint andx-tokenInfoFuncreturns the implementation which calls a local function.