Authentication and authorization are terms commonly used on technology projects and within IT teams. However, their meaning and application are often misunderstood and misrepresented. Some think they mean the same thing and that the two terms are synonyms. Others may tell you they have different meanings but are unable to explain the difference.
In this blog, I’ll explore the meaning of each term and why Business Analysts need to carefully consider these non-functional requirements when leading their teams’ development efforts.
Definitions
Authentication is the process of verifying someone’s identity. Authentication answers the question of “Who are you?”
Authorization is the process of verifying access rights. Authorization answers the question of “What permissions do you have?”
Real World Examples
Example #1
At Core, each employee is issued a badge to access our offices upon being hired. When I place my badge on the card reader at our front door, I am first authenticated as “Kurt Wondra” and then am authorized to enter since I am a current employee. However, it’s important to note that being able to enter the office does not mean that I have access to everything / everywhere. For example, only a few select associates are authorized to access our server room. When I hold my badge up to the card reader there, I’m first authenticated as “Kurt Wondra” (no different than the front office door) but am denied entry since I am deemed as not authorized to access the server room.
Example #2
Many companies provide online portals for employees to remotely access their network. For example, when I log into our company portal, I’m first authenticated as “Kurt Wondra” after successfully keying in my account credentials. Then, after clicking on a call-to-action to access my email, I am shown my inbox since I am authorized to view my inbox. I am not shown Kari’s inbox, nor Amy’s inbox, nor Blayne’s inbox. This is because I am not authorized to do so. From that same portal, our internal IT staff may have an “Admin Menu” where they can reset someone’s password, lock or unlock their account, etc. However, only those associates are granted access to these capabilities based on their authorization.
So Why Should I Care?
Here’s why: a lack of proper authentication and authorization protocols can cause irreparable harm to your customers, users, projects, clients, etc.
Don’t believe me?
Think I’m being over the top?
Then think about this:
- In 2019, First American Bank reported that 885 million users had their financial records compromised over the last 16 years. I don’t know about you, but unauthorized access to my banking records would be a significant concern to me.
- In 2017, sensitive personal information of 148 million Americans was stolen via a data breach. The folks who stole this data were not authorized to access that kind of nor amount of sensitive data of the American public. Consumer confidence in Equifax has plummeted and has failed to return ever since.
- In 2014, weak authentication controls at Home Depot led to a security breach that compromised the payment information of 56 million people. Home Depot estimated the cleanup cost at $179 million (and growing).
Without putting proper authentication and authorization protocols in place, your solution will carry a massive amount of risk and a Mount-Rushmore-sized bullseye on its back.
6 Tips for Ensuring the Right Level of Authentication & Authorization
By reading this blog, you’ve taken the first step towards ensuring your solutions will not be as susceptible as the few we mentioned above. The six recommended tips below will help you plan for the right level of authentication and authorization to be built into your solution.
1. Meet early and often with your Security Team to:
- Document enterprise security standards
- Learn about acceptable solution options for enforcing authentication and authorization
- Schedule recurring penetration testing to proactively identify and address vulnerabilities
2. When writing your Product Backlog Items (PBIs) or User Stories, include who needs to be authenticated to access the information – as well as what authorization levels will be required. Also be sure to document the roles, persons, users, etc. of whom should not be granted access. Consider the following questions to guide you:
- What information is “public”? What information is “private”? And what information is “confidential”? Define each term as it relates to your context and realize you may need to define even more.
- How is authorization to each level of information granted? What process controls exist regarding granting that authorization?
- How will audits be performed to ensure the proper access measures were built initially and remain intact over time?
- What would be the impact of this data falling into the wrong hands? (Think about competitors, hackers, etc.) Consider financial ramifications, brand image issues, customer retention problems, etc.
- What local, state, federal, and/or international laws apply to this information? What level of legal risk could the company be put into? This spectrum spans from bad publicity to bankruptcy. (Think about GDPR, California Consumer Privacy Act, etc.)
3. Consider making authentication and authorization requirements a component of your Definition of Ready for any work item the team will execute on.
4. Build a Roles & Responsibilities Matrix to visually depict who should have access to what.
5. Have the courage to raise your hand when threats are detected. Too often individuals are scared to voice a threat for fear of being perceived as criticizing the development team or for fear of being silenced (“killing the messenger” syndrome).
6. Keep researching and learning; continually sharpen your tools and knowledge on this topic.
Bonus: Consider adding multi-factor authentication into your solutions. This approach is quickly becoming common practice and chances are your users are already familiar with it. This added layer of security is highly recommended over the more simplistic and easier to compromise username and password combinations.
Take Security Seriously
We take security very seriously and discuss authentication and authorization early and often in our client engagements. We even have a dedicated Security Practice that can help you secure your processes and applications.
If you’d like to learn more about how to plan for the right level of authentication and authorization to be built into your solution, then feel free to contact us.
