Deciding Between Authorization Flows

OAuth 2.0 defines several authorization flows designed for different types of security requirements. These provide complete and secure authorization flows for users without users sharing credential information directly with clients. Once you create OAuth 2.0 applications within Liferay, secure tokens provide access to specific scopes of information, making this a convenient and secure method for accessing information. This article explores how to decide between these authorization flows.

Understanding Authorization Flows

To prioritize security and select an appropriate authorization flow, it's essential to understand the available flows and their use cases. Common flows include:

Authorization Code Flow: A user grants permission to the client, followed by your application exchanging an authorization code for an access token. The received JSON is used and persisted to access resources within the granted permissions, which can be paired with an optional refresh token. See Authorization Code Flow for more information.
Client Credentials Flow: The client authenticates with the authorization server using its client ID and client secret, after which the authorization server issues an access token. See Client Credentials and Resource Owner Flows for more information.

Other flows are available but generally not recommended. One such example is the Resource Owner Password flow, where the user's credentials are directly shared with the client. Use this method only when absolutely necessary and strictly limited to highly trusted clients (e.g., first-party mobile applications).

To authorize users using any of the available flows for your registered OAuth 2.0 application, you must construct a URL to the authorization server (Liferay DXP) to authorize requested permissions to resources. The structure of this URL will always require the response_type and client_id request parameters, though its syntax can differ depending on the type of OAuth 2.0 flow in use. See Authorizing Account Access with OAuth2 for more information and URL examples.

Comparing Authorization Flows

The authorization code flow is the most common OAuth 2.0 flow for web applications. This flow offers superior security by exchanging an authorization code for the access token on the server-side, preventing token exposure in the browser or app. Proof Key for Code Exchange (PKCE) further mitigates the risk of authorization code interception in public clients. PKCE's addition makes it secure even for public clients, such as mobile apps and SPAs, where the client secret cannot be safely stored.

If the client will request the URL from a web browser directly, use the authorization code flow with PKCE. Otherwise, the client secret could be leaked, compromising security.

When two servers need to exchange agreed upon, non-user-centric data, consider using the client credentials flow. This flow enables you to bypass the allow/deny screen for users. Since the client authenticates directly with the authorization server using its client ID and secret, this flow is simple and efficient for server-to-server communication or background services. Only consider using this flow when the application is acting on its own behalf, not on behalf of a user.

Recommended OAuth Flows for Each Client Type

Generally, the ideal authorization flow depends on the type of client. When deciding between OAuth 2.0 flows, follow these guidelines:

Application Type	Recommended OAuth 2.0 Flow
Web applications (server-side)	Authorization Code Flow (with PKCE if the web app also has a mobile or SPA component)
Mobile applications	Authorization Code Flow with PKCE
Single-page applications (SPAs)	Authorization Code Flow with PKCE
Machine-to-machine communication (non user-centric data)	Client Credentials Flow

Besides the client type, you should also consider the user experience and the sensitivity of the data being accessed when selecting a flow.

Selecting Clarity’s Authorization Flows

Following best practices, Clarity’s team can leverage the authorization code flow with PKCE within their applications. To support this flow, they can define PKCE as an Allowed Authorization Type when creating the OAuth application. This method leverages a string generated by the client application as an additional code_challenge request parameter. To request authorization codes using PKCE, Clarity can construct a URL containing this code_challenge request parameter:

https://[hostname]/o/oauth2/authorize?response_type=code&client_id=[client ID]&code_challenge=[PKCE code challenge]

When making the final authorization code flow request to get the access token, they can also provide the following parameter:

code_verifier=[Code Verifier that was transformed and sent as code_challenge previously]

See PKCE Extended Authorization Code Flow for more information on this recommended flow.

Conclusion

Prioritizing security is crucial to protect user credentials and access tokens. Selecting an ideal authorization flow ensures high security and mitigates risk of exposed client credentials. The authorization code flow with PKCE is the most versatile and secure option for the majority of use cases, and is the current best practice for most modern applications.

Next, you’ll learn how you can use Liferay’s out-of-the-box APIs to integrate custom applications and data with Liferay DXP, as well as how you can create your own APIs.