Download your copy of our State of Authorization: Playbook Edition Get it now »

What are two common misconceptions around cloud-native authorization?

With any type of technology, there are misconceptions out there around cloud-native authorization. We tackle two misconceptions and uncover the truth.

With cloud-native authorization users have standardized security protocols which enable them to securely access information that is stored in the cloud or within cloud-based software, regardless of their physical location.

But with any type of technology, there are some misconceptions out there around cloud-native authorization.

Here we tackle two common misconceptions around cloud-native authorization and uncover the truth behind them.

1) Cloud-native authorization won’t work with my technology stack

One of the default questions we get asked is, how do you integrate with X technology?

This gets asked often as many organizations think that cloud-native authorization won’t work with the technology stack that they currently own.

This comes along with the thought process that organizations often don’t want to talk with a vendor if they don’t integrate with the technology the enterprise has invested in.

But that isn’t always the way to think about it.

Every technology follows some standard, so there is a way to make cloud-native authorization work with the technology the enterprise has invested in.

Even if we have never heard of the technology before that doesn’t mean that it won’t work.

It requires a bit more research in order to understand the use case and figure out how we can integrate with the technology to make it work for your specific needs.

This can easily be done if someone gives us access to the environment to figure out how we can integrate with it, whether it be as an attribute source or even a proxy.

2) Cloud-native authorization requires a ton of development effort

Yes, a policy enforcement point (PEP) needs to be built and used to communicate with our API and enforced back into the application, but the key thing to remember is that the organization already has the developers in place who are working on building these applications.

By bringing in an authorization vendor, the enterprise is removing the requirement for the developers to think about access controls within the application(s). But this doesn’t mean that the developers don’t need to put effort into bridging the PEP, application and our API.

The next thing we often hear is that the enterprise doesn’t have the manpower to do that, however all it means is that the organization needs to redirect resources to the right places.

With an authorization vendor, it takes away the large part of the decision making process around access management and access controls. This way developers can focus their efforts on what they do best – building efficient applications.

Take the next step

Request a demo with one of our solution experts to learn more about cloud-native authorization with Axiomatics.

You can also download our white paper to learn more.


  Join us on LinkedIn for more insights
Archived under:
About the author

David Morvan is a Professional Services Engineer at Axiomatics, focusing a large part of this time guiding clients in realizing the complete potential of their authorization solution. He has been in technology for 20 years in a variety of disciplines, but highly focused on Data Protection, Data Security, and Identity.