What is OAuth and how does it work?
This topic is important for architects because… architects must be experts in securing web technology.
The main thing you need to know about OAuth is that it prevents you from having to share your password with every web site you want to visit. OAuth (Open Authorization) is an open standard for “token-based” authorization on the Internet. OAuth has become the general and emergent standard for security on the internet.
Ten Minute Four Part Video Explanation
David Rice has a great explanation that should be understandable for anyone who wants a deeper technical explanation than I have provided here.
For Developers Who Want to Get Started Coding
There are a lot of resources for developers who want to get started, but the best one is probably Google’s explanation of how to use their OpenID product at https://developers.google.com/identity/protocols/OpenIDConnect?hl=en
Why is OAuth Difficult to Understand?
OAuth 2.0 can be difficult to understand for several reasons.
Abstractness. Security concepts can be difficult to understand because they are “abstract”. That is, security concepts are often difficult to visualize. To simplify the explanation, we will use the example of a carnival below. Comparing abstract security concepts to something in the physical world makes the concepts a little easier to understand.
OAuth is different. Using OAuth replaces the simpler standard of checking a username and password before granting access to a secured resource. For those of us who have been working on IT for a long time, this means that we essentially have to “unlearn” the simpler methods.
OAuth is complicated. If you consider everything that needs to happen with OAuth, it is “very” complicated. Having said that, focusing on the simplest “flow” makes it easier to understand. To understand the complexity, you can review the 75 page OAuth specification.
Trusted third party. The main difference between traditional username/password and OAuth 2.0 is the use of a trusted third party, an “Authorization Server”, to handle most of the mechanics around security.
What does “token-based” mean? We typically associate security with passing a username and password. In this case, we are passing a more complex data structure that we commonly refer to as “token”.
Authentication vs. authorization. “Authentication” is the process of establishing your identity. “Authorization” is the process of determining what an authenticated user can do after identity has been established. A good example would be a building secured with keycards. Swiping a key card at the front door “authenticates” you for access to the building, but you may not be “authorized” to gain access to every room in the building.
The standard for API security. OAuth is heavily used for API security. That is, it is the standard for accessing REST services and XML web services that are used indirectly by such web applications or for machine-to-machine communications.
Flows. The process of attempting to use a resource, being redirected to OAuth, then using the resource is called a “flow”.
Two versions. There are two versions of OAuth. OAuth 2.0 has been around since 2010. The term “OAuth” is generally accepted to mean OAuth 2.0. OAuth 2.0 is not backwardly compatible with OAuth 1.0, which can simply be disregarded.
OAuth not associated with Facebook or Google. Facebook and Google do use OAuth to provide third-party security for other web sites. A typical example is seen in the image above where the site says “Sign in with Google”. While it makes good business sense for these large companies to provide such services, OAuth is in no way exclusive to any particular third-party provider. Many organizations create their own OAuth servers. The third party providers do make it easy to integrate with OAuth and certainly much easier than creating your own OAuth server. Using a third-party OAuth server such as Facebook or Google is typically no more difficult than pasting some code into your web site as suggested at https://developers.google.com/identity/sign-in/web/
Only for HTTP. Many security protocols can be used with different means of communications. OAuth is specifically designed and intended only for use with HTTP, more specifically HTTPS.
OAuth is not single sign-on. Single sign-on (SSO) and OAuth are often confused because they both provide a means of “sharing” security. SSO is used to allow one account to directly access multiple web sites. OAuth lets a user have many accounts to selectively access services. A layperson can’t tell the difference, of course, but the difference is significant to the IT professional.
The Traveling Carnival Analogy
When I was a child, my parents often brought me to traveling carnivals. Typically, physical security is very limited at a traveling carnival, which would typically be set up in a public park, an open field, or a place of worship. Because the physical security was limited, they used a security system that is a lot like OAuth.
What do you do at a carnival? There are generally three things you can do at a carnival – you can play games of chance, you can eat, or you can ride an amusement park ride.
Purchasing a handstamp. There was nothing to prevent anyone from wandering all over the carnival grounds. The owners would happily allow anyone to play the games of chance or to purchase food without any security. The games of chance and the food was purchased directly. Most people, especially the children, were there for the amusement park rides. Naturally, it gets complicated and time-consuming to let lots of excited children handle money at each ride, so a handstamp would be purchased that lets the recipient ride as much as they wanted to on any of the rides. A rubber stamp is pressed against an ink pad, then pressed on the back of the child’s hand – it then serves as an “authorization token”.
How the analogy applies. The operator for each ride was not concerned about authenticating each child. All the operator has to do was check the “token” (handstamp) the child.
Token Expiration. The handstamps would change color each day so as to allow them to expire. We also allow OAuth tokens to expire. In fact, we could say that the OAuth tokens would be insecure if there no means for them to expire.
A Little More Technical Information
Authorization header. The OAuth information is typically passed from the browser to the server in an HTTP header, the “Authorization” header. When passed along with the HTTP request, it will look something like this example.
Authorization: Bearer 0b79bab50daca910b000d4f1a2b675d604257e42
Bearer tokens? For those who are familiar with the Authorization header, they may not be accustomed to seeing the “Bearer” keyword. The more common keyword is “Basic” for so-called Basic Authentication, which is simply passing a username and password. The “Bearer” keyword was added specifically for OAuth. A Bearer Token is an opaque string, not intended to have any meaning to clients using it. The terminology “bearer” simply implies that if a client presents the token, they can be trusted with whatever the token authorizes without further authentication.
302 redirects. After a client gets the OAuth token from the OAuth server, they need to get back to the original page from the OAuth server, perhaps Facebook or Google. Once the token has been issued, the response from the OAuth server includes an HTTP code 302 redirect command to the browser that forces the browser back to the application that needs the authentication.
Lifetime of a token. A token will always have a limited lifetime, typically 24 hours, but it could be shorter or longer depending on the circumstances.
Token Storage. The OAuth specification does not dictate how the client should store the token. You would typically store the token in session state if you want the client to reauthenticate on their next visit. You could also store the token in some type of database if you want to use the token for a longer period of time. Facebook has been reported to use the same token for 60 days.
Refresh tokens. When a token expires, the general approach to renewing it is to issue a “refresh” token. The OAuth server accepts the OAuth token in a POST request, then can decide to reauthenticate or simply issue a refresh token that will essentially just extend the expiration date.
Four Flow Types
The authorization sequence, or “flow”, that we covered here is the most common one and is known as the “Authorization” flow. The user is shown the screen to enter their credentials and is routed to the OAuth server. There are three other types of flow, but we are not covering them in detail here. There are all intended mainly for machine-to-machine communication rather than human-to-computer communication like the authorization flow.
Client credentials flow. This flow excludes the redirect to the application server and just returns an OAuth token corresponding to the client’s credentials.
Resource owner password flow. This flow excludes the redirect to the application server and just returns an OAuth token corresponding to the user’s credentials. The difference between the client credentials flow and the resource owner password flow is technically modest, but is important from a business perspective.
What is in an OAuth Token?
Many descriptions of OAuth do not show what the actual token looks like. This is for a good reason – the OAuth specification is not specific about what should actually be in the token. Having said that, the most common type of token is the so-called “JSON web token” (JWT).
What is a JWT? It is just a JSON object with all of the information that is needed to use OAuth. The specification is available at https://tools.ietf.org/html/rfc7519. The reason JSON is used is because the entire token can be passed in a URL in either the encrypted or unencrypted form.
What is Base64? When we want to pass binary information over the Internet, it needs to be encoded in a way that the characters are sake to use with Internet protocols. When we encrypt any information, many of the binary numbers in the encrypted format cannot be passed over typical Internet protocols. Instead, the data is transformed into the 64 characters that are safe for passing over the Internet.
What tokens really look like. Tokens are passed encrypted and transformed into a Base64 format. When your application receives the token, it will look something like this.
JWT Decoded and Decrypted Payload Example. There is a little more to a JWT than in the example, but this is the “payload” portion. The actual fields are somewhat variable depending on the provider of the token, but this example is typical.
The definitions of these fields are:
iss – The Issuer Identifier of the response.
at_hash – Access token hash which provides validation of the access token.aud – Identifies the audience that this ID token is intended for. This should be our client_id.
sub – An identifier for the user, unique among all Google accounts and never reused.
email_verified – True if the user’s e-mail address has been verified; otherwise false.
azp – The client_id of the authorized presenter.
email – The user’s email address.
iat – The time the ID token was issued, represented in Unix time (integer seconds).
exp – The time the ID token expires, represented in Unix time (integer seconds). This time should not have passed.
Possible Security Concerns
As with any security provision, OAuth is not perfect and can be subjected to over a dozen common security attacks. Having said that, it is no less secure than using other Authentication mechanisms. In fact, it is more secure because there is less password proliferation – as suggested at the top of the post, that is the main reason to use OAuth. A lot of detail is beyond the scope of this post, but OAuth is only designed to be used in the context of other security provisions.
The key security point with OAuth is that is can only be used with TLS/SSL over an HTTPS connection. This ensures that the transport layer is encrypted and the focus can be on the Authorization. As long as you are encrypting the bearer token and using HTTPS with your web connection, you should not be otherwise overly concerned about security for OAuth.