Learning About OAuth
I recently started learning more about OAuth, this note will document things I learn and find noteworthy.
What is OAuth?
OAuth is an abbreviation for “Open Authorization”. OAuth is an authorization protocol that allows users to give certain permissions to third-party apps and services to access their account without giving them their credentials. Even though there is some authentication protocol built on top of OAuth with OIDC (OpenID Connect), OAuth itself is simply an authorization protocol - which means the protocol doesn’t handle authentication of the user to the authorization server.
How does OAuth work?
There are multiple versions of OAuth, the one most widely in use is OAuth 2.0.
The first version came to life in RFC 5849 .
Abstract
OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.
The second version, OAuth 2.0, came to life in RFC 6749 .
Abstract
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.
Some Differences Between OAuth 1.0 And 2.0
First of all, one should know that OAuth 2.0 is not backwards-compatible, which means that the versions should be treated as different entities.
OAuth 2.0 adds more types of flows to support {native,mobile} applications and more.
OAuth 1.0 uses signatures and more cryptography (HMAC-SHA1 on each request for example) and it’s generally noted as more complex and cumbersome.
OAuth 2.0 is designed with extensions in mind and there are popular extensions on top of the protocol such as OpenID Connect .
OAuth 2.0
We will start to focus on OAuth 2.0 from now since this is the prevalent implementation currently used.
Roles
There are 4 main roles in the flow:
- Resource Owner - entity capble of granting access to some protected resource, also known as end-user when the resource owner is a person.
- Client - application that access protected resources of some resource owner with its authorization.
- Authorization Server - the server that handles the authorization process, capble of issuing access tokens after authenticating the resource owner and getting their authorization.
- Resource Server - the server that handles the resource access - the server that actually has the data the client wants to access.
Client Types
There are 2 types of clients:
- Confidential - clients that can keep their client secrets actually secret.
- Public - clients that cannot keep their client secrets secret.
The OAuth implementation has different guidelines and flows a client can use based on its type.
Flows for Getting An Access Token
- Authorization Code (must use PKCE if public client, advised to use PKCE if confidential)
- Implicit Flow (DEPRECATED and shouldn’t be used)
- Resource Owner Password Credentials (DEPRECATED and shouldn’t be used)
- Client Credentials (must be used only by confidential clients)
- Refresh Token
- Device Code
Authorization Code Flow
- The user wants to let a client access their resources.
- The client redirects the user to the authorization server to get a temporary authorization code.
- The authorization server shows the user a dialog with the client information and the permissions it requested and asks the user if they authorize that request.
- The user confirms the authorization request and is redirected back to the client with an authorization code (by redirecting to the redirect_uri parameter).
- The client uses the authorization code to request an access token from the authorization server.
- The authorization server issues an access token to the client.
- The client uses the access token to access the user’s resources on the resource server.
What are some advantages of OAuth?
- Users don’t need to provide their credentials to third-party apps so there is less risk of their credentials getting leaked or stolen.
- Users can revoke permissions granted to third-party apps at any time without needing to change their own credentials.
- Users can give granular permissions to third-party apps to only access certain parts of their account instead of giving them full-blown permissions and hope they just use what they need.
What are some disadvantages of OAuth?
- The standard is quite complex and there can many various problems in given implementations.
- There’s a risk of misconfiguration leading to security vulnerabilities and maybe even token theft.
- There isn’t a single standard implementation but many fractured ones which may lead to problems found in one implementation to still be open in others.
- Higher latency than just logging in to a single server.