OAuth Example | How OAuth Works

What is OAuth?

OAuth is short for Open Authorization.

OAuth is an open standard used by websites and application to securely exchange information without compromising a user's credentials.

If you've ever "Signed in with Facebook" then you've experienced OAuth.

Want more insights? See our most popular answers to What is OAuth?

OAuth Example

Let's say you want to access your Facebook photos from MySweetApp.com

The client is MySweetApp.com.

The resource server is Facebook.

The authorization server is also Facebook.

The resource owner is you.

1) The client redirects the resource owner to the authorization server (Facebook).

2) The authorization server validates the identify of the resource owner (username/password).

3) The authorization server redirects the user back to the client with an authorization code.

4) The client calls the authorization server again with the authorization code.

5) The authorization server validates the authorization code and responds with an access token.

6) The client uses the access token to make authorized requests to Facebook (in this case, getting a list of friends).

OAuth 1.0 vs OAuth 2.0

OAuth 2.0 is a complete rewrite of the OAuth 1.0 protocol.

OAuth 1.0 requires cryptographic signing with each API request. OAuth 2.0 only requires the Bearer access token with each API request.

OAuth 1.0 has a singular "flow" that doesn't play well with desktop and mobile based apps. OAuth 2.0 has several flows (characterized by grant types) that work better with different application types.

OAuth 1.0 access tokens last indefinitely. OAuth 2.0 access tokens are short lived, are optionally accompanied by refresh tokens, and can be easily revoked.

OAuth 1.0 considers authorization servers and resource servers as the same thing. OAuth 2.0 more clearly separates the roles of these entities.

What is OAuth 2 Flow?

OAuth 1.0 has a singular flow. While this works well with web based apps, it makes for a poor user experience on other platforms For example, some native apps prompt users to open a browser window and retrieve a token manually for their authorization "flow". Not good!

OAuth 2 defines several "flows" for catering to different application types. These "flows" are called grant types and are defined below...

OAuth 2.0 Grant Types

Authorization Code: This flow involves obtaining an authorization code before asking the auth server for an access token (as described in the example above).

Implicit: This flow skips the authorization code part and immediately gets an access token back from the auth server. This grant type was originally developed to help single page web apps avoid CORS related issues experienced with getting an authorization code from a third party URL. This grant type is seldom used today as authorization codes are preferred even for single page web apps.

Password: This is a rarely used but defined flow where applications simply pass a username/password to the authorization server.

Client Credentials: This is a popular flow for service to service communication. An application can request resources it owns from another application with a registered set of credentials. By passing its own username/password to the auth server, the application can obtain an access token without redirecting an end user to a page to enter their info.

For more info, check out the best answers to What is OAuth 2?

How does OAuth work in REST API?

The OAuth framework is specifically designed for REST/APIs.

When developers talk about "OAuth" they are referring to the OAuth 2.0 framework and how it uses RESTful endpoints to securely access user data.

Still confused? Check out the answers to How does OAuth work in REST API?

OAuth vs JWT

OAuth 1 vs OAuth 2 Security

OAuth 1.0 is considered more secure because it enforces encrypted communication. While OAuth 2.0 merely requires the access token to be sent in the HTTP request header, it doesn't FORCE users to use HTTPS...

This means Bearer tokens can be exposed if HTTPS is not handled correctly. And once a malicious user has a token they can do whatever they want within the limitations of that token's scope.

PKCE and OAuth 2.0

Proof Key of Code Exchange (PKCE) is an OAuth 2.0 extension that ensures authorization codes aren't coming from a malicious client. If an attacker were to intercept the authorization code, how would the authorization server know its a malicious client and not the original requestor?

PKCE uses cryptographically generated strings to solve this problem. The calling application generates a cryptographically random string called a code verifier. This random value is then encrypted with a hashing algorithm to produce a code challenge.

When the client requests the authorization code, it also sends the code challenge and the hashing method used to the authorization server.

When the authorization server receives this info, it stores it for later on when the access token is requested.

When the client requests an actual access token, it includes the code verifier in the request payload.

This allows the auth server to validate the code challenge and confirm the request came from the original client.

OAuth 2 vs OpenID

Conclusion

OAuth is a popular framework for securing REST endpoints. Using OAuth, client applications can obtain limited access to a user's protected resources on another application.

OAuth 1.0 is a protocol that relies more heavily on cryptography and lacks the more sophisticated auth flows of the OAuth 2.0 framework. OAuth 2.0 is not backwards compatible with OAuth 1.0.

Your thoughts?