Security Models: Authentication and Authorization Explained

When designing software applications one of the most important design considerations in my opinion is the user security model. I've witnessed countless companies struggle later trying to accommodate various business and revenue models, slowing down their growth, because their security model wouldn't accommodate what sales or marketing wanted. In this article I'll touch on a couple key concepts and I may write future articles breaking down RBAC and ABAC and tips on how to model apps (future proof). These key concepts are authentication and authorization.

A common misconception in security is that "auth" is just "auth" when in reality these two have distinctly different jobs and should be thought of separately. As illustrated above, a good way to think of security is in two steps:

1. Verify an individual is who they say they are and if so, provide them a "pass" for future admittance. This is like you showing your ticket to security at an event (i.e. football game) and them stamping your hand to indicate you've been verified and can come back again later; they may have to give you a wristband if you're over 21. In the context of application security, your "ticket" is your login credentials and once verified they are correct, your "stamp" is a token which is a unique combination of characters that another program can read. The "wristband" is your role (adult) granting you specific privileges.
2. Verify an individual can perform the actions they request on the resource they requested and potentially filter the result. This is like you trying to get into a VIP section at the football game and ordering a beer. A server must first check your ticket to see if your seats allow you access to the VIP section, and then check your wristband to see if you're old enough to order a beer. In the context of application security, your "stamp" (or token) proves you belong and your "wristband" says "I'm an adult" (adult and VIP roles) so you can access the area and order a beer. You may have a child with you who can access the area but cannot order beer so they get a Shirley Temple instead. In this case, their roles were (child and VIP), so they still had access but what they get back after their order has alcohol removed.

Authentication

Authentication is the first step in this two-step process. Modern software applications provide a variety of ways to authenticate users, even trusting verification to third parties also known as identity providers (IdP). I won't dive into federation, SSO, etc. and try to keep this user-friendly but there's a good description of them in this article if you're interested. As described and illustrated above, authentication is simply proving someone is who they say they are and receiving an "endorsement" from a trusted party (either your own system or another).

Tip: use an API Gateway

If your software stack will include multiple APIs in the future, or you'll design/build multiple apps, I'd highly recommend you consider shifting this responsibility to an API Gateway or some other proxy. This way you don't have to rewrite your security functionality in every app. Undoubtedly, older apps get stale and it makes it harder to keep on top of latest threats and update them all. An API gateway I often recommend is Kong but there are several like from Strongloop, AWS, and Ambassador.

Authorization

Authorization happens over an over again after someone is permitted to access your application. Every time a page is requested, or a button is clicked (or tapped/touched/...), your application should check whether that User CAN do what they are requesting.

Explicit role checks vs user privilege checks

I emphasize the word CAN because a remedial approach to authorization is to hard-code role checks within the code like (if user.role = admin) to display a block of functionality. This approach limits the flexibility of your software in the future, and then you must update code everywhere to enable a feature requested by marketing or sales.

The preferred approach is to check (if user.can(Actions.READ, users)) for the feature that requests a list of users. This way you can centralize your authorization models and change them easily over time and your application code doesn't care. For the function or method that returns a list of users, it will always simply check if the requesting user can perform that action on it.

There's another good article by the engineering team at Heap Analytics describing this in further detail that I share with my team and others. I believe many of their engineers are former Googlers and likely implemented these practices at Google as well.

Putting it all together

What trips up a lot of software engineers is how to piece together the security framework to combine authentication with authorization. I see some use the terms interchangeably and that's a mistake because as described, they perform completely separate functions within a software application. Think of authentication as the ticket taker at the entrance to the ball game and authorization as the server in the VIP section; they each have a unique responsibility.

Role-based access control and Attribute-based access control

I'll only lightly touch on these topics. Role-based access control (RBAC) has been around a long time and most engineers have implemented some form of it, even if hard-coded checks which you should not do anymore ;-). This is a way to define roles (i.e. manager, teller, customer, janitor) and then assign permissions to the role. If you assign a user with teller role, they will be able to do everything a teller can do. If you assign them a janitor role, they may not be able to do everything a teller or other roles can do. Typically a user can have multiple roles, so you combine all the things each can do and allow that user to do them all.

Attribute-based access control (ABAC) is picking up steam, but still not as talked about amongst app developers. What this does is add another layer of checks (filter) which may allow you to do something, but in a limited capacity. Like the example of the child in the VIP section who could order a drink, but the drink would have alcohol removed, a user might request a list of users and could see them, but their IDs and phone numbers were removed. A manager could request that same list, but they could see IDs and phone numbers. Think of HR systems where you don't want employees to see salary details of their colleagues, but they should be able to see them. Then HR could see the same list, but they'd also see the salary details and deductions. This "filtering" is known as ABAC.

Summary

As you've learned, there is a clear distinction between authentication (allow access) and authorization (grant permission). Using the ticket taker versus VIP server hopefully you see that each has unique responsibilities within your software. In order to future proof your software, you should simply check if a user CAN perform an action on a resource. By considering ABAC from the start can allow you ultimate flexibility in the future when sales, marketing, or product owners request features that use filtering to differ the level of access to a record based on a specific user role.

In a future post I hope to illustrate how to implement an end-to-end security framework using popular technology stacks like NodeJS and identity providers like Okta or Auth0.

Next Article Is Available 1/9/2019

View the next article on this topic: Authorization Modeling By Example