Securing your application, the new normal

It’s hard to remember a time when we didn’t have to worry about data security. With the rise of cloud computing, many users are experiencing new levels of vulnerability. This blog post will cover how authorization works in modern applications and why our old way of doing things just won’t cut it.
Before we jump down the rabbit hole, let me first take some time to establish some base context. When talking about authorization, it’s hard not to also talk about her twin sister, authentication. The two go hand in hand and are often confused for one another. The reason is that the flow of how someone is granted access is so fluid that it’s not often evident when you’ve crossed the boundary from authenticating someone to authorizing someone. So let’s draw those lines now.

Authentication is the process of verifying someone is who they say they are. This might mean looking at their username and password or checking that a cell phone number matches an email address on file for them. It’s about proving identity, not granting access rights to specific application parts (though those can also come into play).

Authorization is granting access to a specific part of the application. This might mean looking at the access token passed with the request, or it can be checking that the role of “admin” was granted to this user on your application.

Now that we’ve set those lines, let’s dive into what it means to secure an application from an authorization perspective. The most common form of authorization is to attach permissions to a user account. This allows access only when the application verifies that you’re signed in with an active account and has the correct permission. The application will reject any requests from other users or bots. When determining what functions should require permission, consider whether they would be regarded as sensitive data: your profile information, location, grandma’s pancake recipe, and things like that.
This strategy is an excellent way to protect data for the most part, but it falls short when we have multiple users with different permissions who all need access. What if you want your marketing team to be able to see only their campaigns? In the past, we solved this with roles and groups, and while it gave us the functionality we were looking for, it also provided an administrative nightmare that we weren’t looking for. We ended up with systems with more groups than users in the system, and nested groups within nested groups, which all led to access being granted when we didn’t want it to be.

Scalability is always a problem with these solutions, which are complex to manage. When we find ourselves where our business needs are changing quickly, this system can’t keep up easily. Add to that the fact that we now build applications to share data from the beginning, and we’ve got a mix of different users, a matrix of permissions, and a lot of data passed around at the click of a button. Yikes.

In modern applications, we need to quickly get data in and out of a system. When we find ourselves with massive datasets — becoming more common- this type of efficient authorization becomes even more critical. This is why token-based authentication has become so popular among API providers: it enables us to grant access to users in a stateless way by giving them a token that identifies who they are, and it can also contain attributes that tell the application what that user can do within that application, which gives us the ability to implement authorization strategies.

One of the most popular and secure token-based frameworks is OAuth which has been around since 2007. A huge reason for its popularity is that it’s more than just a simple protocol: it contains many strategies for negotiation between an application (usually written in JavaScript) and a service provider about how to handle authorization. So when planning out your application, you should consider which strategy would work best for your users and your application. You want to understand what type of access your users need. Is there admin functionality? Are there power user settings? Based on that functionality, what data should be accessible to those users? What type of users will you have, and how will they access your application? These answers will help you pick the right OAuth strategy for your application.

Once you have your strategy, you want to understand what authorization elements you wish to use to control access. OAuth gives you the ability to create scopes. A scope is a set of access rights. You may need to create multiple scopes depending on your strategy for authorization. Be careful here; this can lead down the same path we’ve seen before with groups and roles. While you want to have well-defined scopes that map to function within your application, you don’t want to have a scope nightmare of more scopes than users. Every user must provide their credentials and consent before gaining access to the application or data within it — this is an essential step in securing your application!

This is to say that authorization has become essential to modern applications. But it’s not enough for developers to implement a token system and call it done. You need to be mindful about which tokens you issue, which scopes you implement, and how you govern the access they grant because if you don’t, it can lead to unintended consequences (like giving access to something it shouldn’t). Even something like token-based authorization will do more harm than good! Leave some comments and let me know about your authorization journey, and stay tuned for more tips on securing applications.