Authentication vs Authorization
Understanding the difference between the two commonly used terms in the identity and access management
Often times, we interchangeably use Authentication and Authorization terms in order to represent ways to protect applications and/or services. In this article, I’ll dive deep into their subtle yet important difference.
Authentication: In layman terms, it’s a process to verify who is the user and are exactly who they claim to be.
Authorization: It’s a process to confirm what kind of access the authenticated user has.
Key Characteristics of Authentication:
Validates that user is exactly who they claim to be.
Prompts user to enter credentials (or ways to identify themselves)
Username and passwords are the most common form of authentication.
This step is performed prior to Authorization.
OpenID connect protocol is used as a common security protocol.
It moves data using ID tokens.
For example, if an employee logins to their company website, internal only to employees, they will need to first authenticate using their key (in the form of passwords, biometric, third party apps, pin, etc.) to verify their credentials.
Key Characteristics of Authorization:
Validates if a user has access to the underlying resources.
Verification is done using the resource policies and rules established during access management of a resource.
Access Tokens are used to move this data.
OAuth2.0 is used as a open standard for Authorization.
For example, after an employee authenticates using their credentials, they can still be denied access to a resource if the resource policies doesn’t authorize that user.
With the sites such as Google, Facebook etc., user can login to them and use those credentials to login to other websites. Or, if an organization is trying to restrict the access of their resources to employees only, then instead of asking credentials on every web page, employees usually login at one place and use it to authenticate elsewhere. This entire process is called SSO (Single Sign On) and OpenID is used by the identity providers to initiate authentication in the first place (in above examples, Google/Facebook/Internal portal are examples of identity providers).
OpenID issues an account to the user when they register with the identity providers. Every registered user gets a <user’s open id>.openid.com url which is unique and this account is then used to authenticate wherever OpenID authentication is accepted.
Some of the largest organizations such as Google, Yahoo, PayPal etc use it to provide authentication to users.
When a user authenticates, they are granting access to their client on a HTTP service to retrieve resources without actually sharing the credentials with the server. This communication is done using the access tokens that are issued by the identity provider. OAuth helps in providing limited access to user data and allows sharing of resources even without releasing user information.
Having a strong understanding of both of these concepts will help in building stronger rules/policies to protect unwanted access to confidential resources. Hence, a combination of good authentication and authorization is required to prove identity of a party trying to access a resource.
If you like the post, share and subscribe to the newsletter to stay up to date with tech/product musings.
(The contents of this blog are of my personal opinion and/or self-reading a bunch of articles and in no way influenced by my employer.)