X: https://twitter.com/_jgoebel
Website: https://jangoebel.com

00:00 What is OAuth 2.0?
00:13 What problem does OAuth 2.0 solve?
02:04 OAuth 2.0 client registration
03:06 OAuth 2.0 Confidential vs. public clients
04:21 OAuth 2.0 Authorization Code Grant
06:43 OAuth 2.0 Access and Refresh Tokens and JWTs
08:03 OAuth 2.0 permission types: Client credential permission, implicit permission, resource owner password permission, device permission
09:03 Outro

OAuth 2.0 is an /“authorization framework [that] enables third-party applications to obtain restricted access to an HTTP service/” (RFC 6749).

OAuth 2.0 is all about granting third-party applications limited access to APIs. Before OAuth 2.0, the third-party provider would have asked for the user's credentials and used those credentials for the respective API. OAuth 2.0 eliminates the need for password sharing by introducing a new entity called the OAuth 2.0 Authorization Server.

The OAuth 2.0 authorization server issues access and refresh tokens to third-party applications, eliminating the need to share credentials. The third-party application is called a client in OAuth terminology. The API that the third-party wants to access is called a resource server or protected resource.

Before a third party can gain limited access to an API, it must first register with the OAuth 2.0 authorization server. The third party application, called the client, receives a client ID when registering with the OAuth 2.0 authorization server. If the client can keep data secret, it also receives client credentials. The simplest form of a client credential would be a shared secret, called the client secret. OAuth 2.0 also supports more sophisticated means of authenticating to the OAuth 2.0 authorization server, such as mutual TLS (mTLS).

Once the client is registered, it executes one of the OAuth flows, also known as grant types. The most popular grant types are the OAuth 2.0 Authorization Code Grant, which orchestrates an approval flow between the resource owner, the OAuth 2.0 authorization server, and the protected resource.

Compare this to client credential assignment, which is intended for machine-to-machine communication. Resource owner password assignment and implicit assignment are insecure according to current OAuth 2.0 security best practices and must not be used. Then there is OAuth 2.0 device assignment, which is intended for devices that do not have a browser or where entering credentials is cumbersome, such as smart TVs.

Although the OAuth 2.0 RFC does not require the access and refresh tokens to be structured, most deployments are actually JSON Web Tokens (JWTs). This has the advantage that the protected resource can validate the token's signature locally without having to make a REST call to the authorization server to check the token's validity.

Picasso artwork: https://www.freepik.com/free-vector/hand-drawn-picasso-style-illustration_29679617.htm Image by Freepick

Artist: https://www.freepik.com/free-vector/artist-art-tools-set_3813261.htm Image by macrovector on Freepick

Software developer: https://www.freepik.com/free-vector/binary-code-concept-illustration_15581993.htm Image by storyset on Freepick

Please take the opportunity to connect with your friends and family and share this video with them if you find it useful.