Feb 01 / 2017
Enterprise Identity and Access Management: Authentication vs. Authorization
firstname.lastname@example.org (Christian Duvall, Group Vice President, Enterprise Services)
In the world of Enterprise Identity and Access Management,there is a vast glossary of terms, some of which are easily confused. Maybe it's due to the similarity (e.g., authenticate, authorize, authority) or maybe it's the complex and ever-maturing landscape of IAM services, but it's not uncommon to hear words being confused or misused. In this post, we're going to take on the differences between authentication and authorization, providing you with some helpful ways to differentiate between the two terms.
First, a quick definition of authentication vs. authorization courtesy of our guide, “Identity and Access Management: A Primer on Terms and Concepts:”
“Authentication verifies a user's identity, and Authorization verifies a user's access.”
While it is an intentionally oversimplified synopsis, this sentence highlights the most important distinction between the two terms. On its own, the definition may not add sufficient clarity. However, with a little more digging, it will be a quick way to remember the differences.
Authentication is something that happens every day, in real life, even outside of the world of information systems. When you go to the store and pay with a credit card, the cashier may ask for your ID. In this way, the store care verify your identity before attempting payment. The store won't yet know if you can actually use the credit card, but at this point you are who you say you are, so an attempt to make the payment is allowed.
For information systems, the most common process for authentication is the classic "sign-in," where a user provides a username and password to establish identity. Often, this step is all you need to get access to all of a system's features, which is another reason that authentication and authorization can be mixed up.
No matter the medium, the goal of authentication is to determine that you are – in fact – you. The benefits of being you, as amazing as they might be, do not yet come into play.
Continuing with our analogy, once the cashier swipes your credit card, a message is sent to the bank requesting access to complete the payment. Your credit card numbers, expiration date, the requested transaction amount, and sometimes even the security code are sent along to verify the transaction. This is the authorization. The authorization process is going to check a lot of things, such as:
- Are the credit card numbers correct?
- Is the card expired? Does the expiration date match the card?
- Is the credit card limit high enough for the transaction?
Any of those details could deny access to the desired outcome – a completed payment. The best part of this example is that the authorization in this scenario actually *is* an example of an information system. On the other side of that credit card reader is an entire access management system, built around determining whether transactions can and should be made.
It's actually pretty interesting to think about the similarities and differences of this common scenario and what an Identity Provider (IdP) might do. The bank relies on the vendor to ensure the credit card being used belongs to the possessor. But, this version of your identity isn't explicitly passed along. Rather, the credit card information itself becomes a token of who you are and it stands on its own for the bank's portion of the transaction.
This is not all too different from what an identity provider would do after a successful sign-in to a system. The IdP would provide a token to the consumer, and from that point on, it would be deemed adequate to represent the identity of the user.
We hope you enjoyed this brief comparison of authentication and authorization! If you’re interested in learning more about the fundamentals of Enterprise Identity and Access Management, such as methods of authentication, multi-factor authentication, and single sign-on – sign up to receive our Primer on Terminology and Concepts.
P.S. Don’t forget to subscribe to receive future blog posts directly in your email!