There are two main parts to OAuth 2.0: obtaining authorization by the user (the end result being the application has an access token for that user), and using the access token to make requests on behalf of the user. The methods for obtaining an access token are called flows.

OAuth 1.0 started out with 3 flows, for web-based applications, desktop clients, and mobile or “limited” devices. However, as the specification evolved, the three flows were merged into one which, in theory, enabled all three client types. In practice, the flow worked fine for web-based applications but provided an inferior experience elsewhere.

As more sites started using OAuth, especially Twitter, developers realized that the single flow offered by OAuth was very limited and often produced poor user experiences. On the other hand, Facebook Connect offered a richer set of flows suitable for web applications, mobile devices, and game consoles.

OAuth 2.0 addresses this by defining multiple flows again, called “grant types,” with flexibility to support a wide range of application types. There is also a mechanism to develop extensions to handle use cases not previously thought of.

Server-side apps use the “Authorization Code” grant type with a client secret, which prompts the user to authorize the application, and generates an authorization code that is handed back to the app. The app’s server then exchanges the authorization code for an access token. The security of this flow is obtained by the fact that the server-side app uses its secret to exchange the authorization code for an access token.

Single-page or mobile apps use the same grant type, but don’t use the client secret. Instead, the security is in verifying the redirect URL as well as the optional PKCE extension.

OAuth 2.0 officially defines a “Password” grant type, allowing applications to collect the user’s username and password and exchange them for an access token. While this is part of the spec, it is intended to only be used by trusted clients, such as a service’s own first-party application. It should not be used by third-party apps as that would allow the third-party app to have access to the username and password of the user.

The “Client Credentials” grant is used when an application is access its own resources. This grant type is simply exchanging the client_id and client_secret for an access token.

OAuth 2.0 also supports extension grant types allowing organizations to define their own custom grant types to support additional client types or to provide a bridge between OAuth and existing systems.

One such extension is the Device Flow for authorizing apps on devices that don’t have a web browser.