Module 4 | General Web » Security
Students should be able to:
OAuth stands for "Open Authorization" and can be defined as:
an open standard for implementing token-based authentication and authorization
The term "open standard" is a little vague, but essentially describes a specification that is open to the public and free to be implemented by application developers.
OAuth allows your account information from one application (e.g. Twitter) to be used by another application (e.g. TweetDeck), without having to expose or share the user's credentials between apps. OAuth acts as an intermediary on behalf of the user, negotiating access and authorization between the two applications.
You'll often hear the two words authentication and authorization used interchangeably - we've already thrown them around a bit in this lesson - but they actually have two very different meanings. The process of authentication answers the question "Who are you?", while authorization answers the question: "What are you allowed to do?".
For example, I build a contacts application called NewPhoneWhoDis that manages all of my contacts on various social accounts. I first authenticate my application with Google, telling them that I am NewPhoneWhoDis. I then authorize my application to give it permissions for reading and writing changes to my Google contacts list.
Remember that OAuth stands for "Open Authorization". While the OAuth flow handles authentication, its main emphasis is on the authorization process. OAuth doesn't pass authentication data between consumers and service providers - but acts as an authorization token of sorts.
OAuth is an important part of creating secure applications. We mentioned previously that an OAuth service provider acts as an intermediary to negotiate access to other application data. This intermediary role prevents us from having to give away our credentials by providing us with access tokens instead.
OAuth provides us with a secure way to build applications that rely on pre-existing datasets that may contain private information. Take a few minutes to watch this video on why OAuth is important:
OAuth 2.0 - Why It's ImportantThe user who authorizes an application to access a protected resource
An application that wants to access a protected resource on behalf of the Resource Owner
The server hosting the protected resources (The API you want to access)
The server that authenticates the Resource Owner and issues Access Tokens
The act of generateing a token to identify a user is considered the authentication "handshake". You'll hear this term handshake used frequently to describe an authentication mechanism. It simply means that a client (in our case, the browser), is telling a server:
"Hi, nice to meet you, I am Bob Loblaw and I would like for you to trust me. Here are a couple facts about myself."
And the server looks Bob Loblaw up and down, writes down all of his information and says:
"Ok, Bob Loblaw. I trust you on one condition: you must provide me this secret password every time we do business."
And the server gives Bob a token that has encoded all of Bob's information and permission levels. Bob can now use this token as a "keycard" to send and receive data from the server.
This token-based authentication flow is what is used in implementations of JSON web tokens. In fact, some OAuth service providers like Auth0 use JSON Web Tokens in their implementation.
We've now learned about a couple different authentication mechanisms for working with APIs. Take a moment to read the following blog post on the differences between each of them and their best use cases:
API Keys vs. OAuth Tokens vs. JSON Web TokensIn the tech world we have a tendency to want to build things from scratch or reinvent the wheel. (Exhibit A: npm has 3,346 packages related to the fetch API.) While that's all well and good, authentication and authorization are not areas that you want to implement on your own. Rolling your own OAuth will be wrought with vulnerabilities and security holes unless you have a full team of security engineers working on maintaining its integrity. It’s easy to introduce security holes if you're not familiar with that area of development or you're not actively and consistently looking for weaknesses.
There is a thing called Schneier's Law which generally states:
"any person can invent a security system so clever that she or he can't think of how to break it."
Essentially, the security system you build is only as good as your security skills. There are a lot of seemingly minor features (user enumeration, lockout intervals, https, etc) that have a huge impact on the effectiveness of a security system. While we're used to being able to pare down a project scope to an MVP, you cannot take shortcuts when rolling your own authentication.
Lucky for us, there are plenty of pre-existing tools we can use for hooking into authentication for applications like Google, GitHub, Facebook, Twitter, etc. Two you might hear about are Firebase and Auth0.
Firebase is a product created by Google that provides a collection of tools for building a full-featured application without having to create your own backend. Firebase provides database management and authentication, among other things.
With Firebase, we can create a new application and enable authentication for Google, GitHub, Facebook, Twitter, etc. While Firebase provides us with many different tools for application development, we recommend only hooking into it for authentication purposes. You have your own backend skills, you don't need to rely on the other features of Firebase to build your applications.
Auth0 is a bit newer, and has a strong emphasis on the use of JWTs. It provides the authentication and authorization features and allows us to hook into the same types of accounts as Firebase. Unfortunately, because Auth0 is so young, it's also been notorious for implementing breaking changes which have caused applications to stop working in the past. Advice: Use with caution.
We'll get some quick familiarity with the Firebase syntax and API, and see how the UI works when authenticating with Google through Firebase. We're going to create simple, single HTML file that has a sign in button that allows you to authenticate with Google. When you click the button again, it will sign you out.
python -m SimpleHTTPServer in the terminal (defaults to port 8000) or by doing a global installation of the npm http-server module and running http-server.