Internet users put a lot of faith in companies and services when they allow them to use and store their sensitive data. Each time a user creates a new account online, they are required to create a new username and password and may be asked for other personal information. I, for example, have numerous online bank accounts and I am not too keen on the idea of this information getting into the wrong hands. It's imperative that we as developers prioritize the safety and security of user data when developing new applications. Authentication and authorization can be thought of as the first step in safe handling of user data. User authentication and authorization is a means of confirming the identify of users and ensuring they are accessing the correct resources while online:
Authentication
When I go online to check my bank balance, the bank's website will prompt me to enter my login credentials. The bank will use this information with its authentication server to verify my identity. I don't want any schmuck off the street to imitate me online and have access to my account. Authentication is typically handled using a unique username and password. When I first create my account at the bank, I will be prompted to choose a username that hasn't already been chosen by another user at that bank. Think of the potential headaches if multiple users had an identical username. Once I've come up with the perfect username, I must choose a password that follows the site's password guidelines (note: please don't use password1234 for every website you visit). The bank will most likely ask for additional sensitive information to verify the user's identity, including an address or social security number. Once the bank has gathered this information, it will confirm the user's identity and allow them to access accounts through a secure login.
Authorization
Now that I have created an account (and trusted an online bank with my precious information), I can use my authentication credentials to access my bank account. After struggling to remember my password, I'm finally logged in. Great! The bank has authenticated my identity and knows who I am. What happens now? The answer is that authorization takes the baton from authentication. In the same way that we don't want anyone to access our bank accounts, we don't want other authenticated users on the bank's site to be able to access our private information. Authorization is used to inhibit users from accessing resources and information that does not pertain to them. A user shouldn't be able to login and see their neighbor's bank account balance (unless their neighbor was kind enough to offer up their credentials). Authorization applies restrictions to the application that ensure the server is responding with resources that only I am allowed to see and use.
What is OAuth?
OAuth stands for open authorization and it is a standardized protocol that developers can use to allow the sharing of private user data without sharing usernames and passwords across web applications and services. OAuth 2.0 was released in 2012 and is not backwards compatible with the original OAuth. OAuth 2.0 relies on the passing of request tokens and access tokens that authenticate the identity of the user and allow an application to access resources on behalf of that user. OAuth 2.0 provides a workflow that developers can follow to integrate third-party authentication into their applications. The general flow of OAuth is as follows:
The app asks for the user's permission to access a service on the user's behalf (i.e. their Google Account).
With the user's consent, the app now asks Google for a request token. Google will respond with a request token that gets passed back to the User.
The user will be prompted to login to their Google account, which will authorize the request token and send the authorized request token back to the app.
The app will now send the authorized request token to Google and say, "Hey look, this user has been authenticated and I can access resources on their behalf"
Finally, Google will respond with an authorization token that grants the app permission to use the client's resources. This authorization token is passed back and forth between the app and Google each time the app needs to access a resource.
In order to emphasize the utility of OAuth, let's continue with our bank example. Say I have just downloaded a new app that lets me keep all of my personal finance information in one place. This app allows me to track my monthly spending by connecting all of my bank and credit card accounts and accessing their balances and statements. Although I may trust this finance app, it's probably not the best idea to give them the credentials for all of my banks and other accounts. If I were to provide this app with the usernames and passwords for each of my bank accounts, they are now sitting on the company's servers somewhere waiting to be exploited. A better option would be to have my bank authorize the application and allow it to view my balances and transactions while never handing over my credentials. The beauty of OAuth is that it reduces the need for users to create accounts at every site they visit and greatly cuts down on the amount of personal information floating around on the internet.
I hope that my brief introduction to authentication, authorization, and OAuth clears up some of the confusion surrounding these topics. I look forward to implementing OAuth into my future applications as it is a great tool to protect users and improve user satisfaction!
Top comments (0)