The Challenges of Using OPA for Application Authorization

What does OPA offer?




  1. Using an HTTP call to inject data from an external service compromises the integrity of the decision made by the engine since the policy can no longer be considered to be immutable and read-only.
  2. In the application authorization use case, the engine is expected to make a decision for every application request, which means decisions have to be made in milliseconds and there’s no time for expensive network calls.
  3. JWT/SAML tokens are limited in size and might not be adequate for transmitting all information required for making an authorization decision.


  1. Overloading input — the application itself will provide the information regarding the resource accessed. This approach is problematic because it allows the decision engine to be influenced in unexpected ways by the application state. In an ideal situation, all data points used by the decision would come from a trusted source that can’t be tampered with.
  2. Bundle API — the resource information will be packed into the bundle (in the data.json file). This approach means that the resource data will have to be memory resident, which may be prohibitive in cases where there are many resources.
  3. Push data — A similar approach to the Bundle API, it suffers from similar drawbacks. Using this approach, data is replicated from a database into the OPA decision engine, where it lives in memory.
  4. Pull data — Using a built-in function like http.send, to retrieve the required data. This approach is problematic since it increases the processing time of each decision and might not be feasible for most application authorization use cases where a sub-millisecond response is required.

Decision logs




Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store