3 ms·

This isn't a new idea. This exact proxy pattern already exists with things like AWS API Gateway Lambda Authorizers. This is still quite a useful architecture a

This isn't a new idea. This exact proxy pattern already exists with things like AWS API Gateway Lambda Authorizers. This is still quite a useful architecture as it allows the backend to be implemented without concern for authentication or authorization. You just have to make absolutely sure that nobody can reach the backend except via the proxy. The one downside is that it limits authorization to simple yes/no. The user may proceed with this API call, or they may not. There are occasions where you may want to allow the API call, but alter the results based on authorization. For example, a user wants to list objects, which you want to allow, but you only want the list to contain objects the user is permitted to view. In this case you can't completely avoid implementing authorization on the backend. The proxy has to tell the backend the user's identity, and the backend has to implement some logic based on that.

asafc 3y ago
Good catch, I think that built-in data filtering can actually be a good addition to this new standard. I imagine a rego rule in OPA (or any other policy language) can accept the result json and modify it in place before sending the sanitized/filtered response back to the frontend client. This is not very performance efficient though - maybe if the source api supports it, the proxy can inject filters (via headers / query params) to the modified request based on the authorization policy.
orweis 3y ago
True a gating reverse proxy isn't a new idea- but combining it with frontend only login, policy as code, and secrets injections from a vault to produce authorization you can use seamlessly from the frontend kinda is ;-) As asafc mentions, and as noted in the RFC (https://foaz.io/standard/RFC#foaz-service-reshapes-requests-and-loads-it-with-needed-secrets https://foaz.io/standard/RFC#foaz-service-reshapes-requests-...) - " Optionally the policy itself could be used to reshape the request." - the policy engine can be used to adjust the api call

asafc 3y ago

Good catch, I think that built-in data filtering can actually be a good addition to this new standard. I imagine a rego rule in OPA (or any other policy language) can accept the result json and modify it in place before sending the sanitized/filtered response back to the frontend client. This is not very performance efficient though - maybe if the source api supports it, the proxy can inject filters (via headers / query params) to the modified request based on the authorization policy.

orweis 3y ago

True a gating reverse proxy isn't a new idea- but combining it with frontend only login, policy as code, and secrets injections from a vault to produce authorization you can use seamlessly from the frontend kinda is ;-) As asafc mentions, and as noted in the RFC (https://foaz.io/standard/RFC#foaz-service-reshapes-requests-and-loads-it-with-needed-secrets https://foaz.io/standard/RFC#foaz-service-reshapes-requests-...) - " Optionally the policy itself could be used to reshape the request." - the policy engine can be used to adjust the api call