Frequently Asked Questions

Why do I need Gate?

In a microservice environment your authentication and authorization logic responsibilities are spread across different teams causing a security risk and reducing development speed. Gate allows you to separate identity concerns from application logic.

Do I need to use SlashID as my IdP to use Gate?

You don’t have to. However, using SlashID allows you to leverage our Data Vault which helps you implement ABAC and Data Governance.

Does Gate run on premise?

Yes, Gate is distributed as a docker image or a statically-linked binary that you can deploy in your own environment.

What kind of authorization logic can I implement with Gate?

Gate allows you to perform RBAC, ABAC and more complex authorization logic through our scripting engine which also embeds an OPA interpreter.

I already have an API Gateway, why should I use Gate?

Modern API gateways support certain identity-related operations such as JWT token validation; however, they don’t help you with authorization, token and policy management or m2m auth. Further, they can’t be deployed as sidecars reducing your performance and ability to adopt a true zero-trust posture.

I have a monolith and I don’t plan to migrate, is Gate for me?

Gate works best in micro-services environments. However, it is still a valid choice to offload identity responsibilities to a separate service.

My gateway has a plugin to work with my IdP. Do I still need Gate?

If your only requirement for your backend is validating tokens at the gateway level, you won’t need Gate. However, Gate is still the right answer for you if you want to perform more complex token manipulation (such as translating tokens to an internal representation or augmenting tokens with specific per-service attributes), perform authorization logic, reconcile/have multiple IdPs or need to implement data governance. Gate is also the right answer if you have multiple/legacy Gateways.

My authN/authZ logic is implemented through a middleware by the application team, why should I change that?

Not having a centralized authZ/authN management layer makes any token modification significantly harder to perform. Further, it doesn’t provide the guarantees you need in terms of uniform enforcement of up-to-date authN/authZ policies. If you ask your application team to implement authN/authZ you will have similar implementation but not a consistent implementation across your environment, resulting in higher cost of change and maintenance.

I have a service mesh, is Gate compatible with that?

Yes! Gate was primarily built with a service mesh/sidecar pattern in mind.

Why should I not build this in house?

Distributing policies, implementing distributed rate limiting, detecting anomalous behavior and having a scripting engine and out-of-the-box connectors for major IdPs is a lot of work that is non-core to your business and very error prone.

My API gateway/service mesh can do JWT validation, what does Gate give me?

Gate is still the right answer for you if you want to perform more complex token manipulation (such as translating tokens to an internal representation or augmenting tokens with specific per-service attributes), perform authorization logic, reconcile multiple IdPs or have a data governance controller as well as if you have a need for more advance identity analytics.

Can I deploy Gate through Terraform?

Yes.

Can I use source control for Gate policies?

Yes.