About OAuth2 OOB (Out-of-Band) Flow

The OOB (Out-of-Band) flow in OAuth2 is a legacy flow where the authorization code is delivered to the client application through an out-of-band mechanism, such as manually copying and pasting the code, rather than being automatically redirected via a "redirect_uri". This flow was historically used for applications that couldn't securely handle redirects, such as native or mobile apps, but it has largely been deprecated in favor of more secure flows like PKCE (Proof Key for Code Exchange).

While most modern OAuth2 providers have moved away from requiring the OOB flow, there are still a few scenarios or providers where it might be used or supported:

OAuth2 Providers That Support or Require OOB Flow

  1. Google OAuth2:
    • Google historically supported the OOB flow for native and mobile apps, but it has deprecated this flow in favor of PKCE.
    • As of October 2022, Google no longer allows new OAuth clients to use the OOB flow ("urn:ietf:wg:oauth:2.0:oob"). Existing clients may still use it, but new clients must use PKCE.
    • If you're working with an older Google OAuth client, you might encounter the OOB flow.
  2. Microsoft Azure AD:
    • Azure AD previously supported the OOB flow for certain scenarios, such as device code flow or legacy applications.
    • However, Microsoft now recommends using PKCE for native and mobile apps.
  3. Auth0:
    • Auth0 supports the OOB flow for specific use cases, such as device authorization flow or legacy applications.
    • You can configure Auth0 to use "urn:ietf:wg:oauth:2.0:oob" as the "redirect_uri" for testing or development purposes.
  4. Legacy or Custom OAuth2 Providers:
    • Some older or custom OAuth2 implementations might still require the OOB flow, especially if they were designed before PKCE became widely adopted.

How to Identify OOB Flow

If you're working with an OAuth2 provider and need to determine if it supports or requires the OOB flow, look for the following:

  • The provider's documentation mentioning "urn:ietf:wg:oauth:2.0:oob" as a valid "redirect_uri".
  • Support for manually entering an authorization code (e.g., in a desktop or CLI application).
  • Legacy documentation or examples referencing the OOB flow.

Example of OOB Flow

Here’s an example of how the OOB flow might work:

  1. The user initiates the authorization request in a browser.
  2. The authorization server displays the authorization code on the screen instead of redirecting to a "redirect_uri".
  3. The user manually copies the code and pastes it into the application.
  4. The application exchanges the code for an access token by making a request to the token endpoint.

Modern Alternatives to OOB Flow

If you're building a new application, it's strongly recommended to use modern, secure flows like:

  • PKCE (Proof Key for Code Exchange): Designed for public clients (e.g., mobile and single-page apps) to securely obtain tokens without a client secret.
  • Device Authorization Flow: Used for devices with limited input capabilities (e.g., smart TVs).

Conclusion

While the OOB flow is largely deprecated, you might still encounter it in legacy systems or specific providers like Google, Azure AD, or Auth0. For new applications, use PKCE or other modern OAuth2 flows to ensure security and compliance with current best practices. If you need to use the OOB flow, check the provider's documentation for specific instructions.