Legacy Patterns: The Password Grant and Migration Strategies

An authorization grant is the specific mechanism an OAuth 2.0 client uses to obtain access to a protected resource. Historically, developers relied on a variety of grants to accommodate different application architectures. Among these, the Resource Owner Password Credentials (ROPC) grant, often simply called the password grant, was widely used. However, modern security standards have deprecated this flow entirely.

In this lesson, we examine how the password grant works to help you recognize it in legacy systems, understand its inherent vulnerabilities, and identify the correct migration paths for modern Spring Security applications. We also clarify a common misconception from older architectures: access tokens are not inherently JSON Web Tokens (JWTs); they can be opaque strings or JWTs, depending entirely on the authorization server's configuration.

The mechanics of the password grant

To effectively modernize a legacy system, we must first understand how it currently operates. The password grant is a direct, two-step flow in which the user provides their actual credentials to the client application, which then acts as a middleman to obtain a token.

The client application prompts the user for their authorization credentials, typically a username and password. The client then sends these raw credentials directly to the authorization server via an HTTP POST request, along with its own client identification.

• Line 2: The grant_type explicitly tells the authorization server to expect raw user credentials.

• Lines 3–4: The client application authenticates itself using its registered ID and secret.

• Line 5: The requested scope of access.

• Lines 6–7: The raw credentials collected directly from the user interface of the client application.

If the credentials are correct, the authorization server responds with a JSON object that contains the tokens.

• Line 2: The token_type indicates how the token should be used in subsequent requests (typically as a Bearer token in the Authorization header).

• Line 3: The expires_in field is an integer representing the lifespan of the access token in seconds.

• Lines 4–5: The server issues the access token and, optionally, a refresh token to maintain the session without prompting for the password again.

While this exchange looks simple and requires very few architectural decisions, that simplicity hides significant structural flaws. To see where this flow breaks modern security boundaries, look at how data crosses trust boundaries.

As the diagram illustrates, the immediate collection of credentials by the client is the fundamental design flaw of this legacy pattern.

Security risks and trust boundary violations

The primary purpose of OAuth 2.0 is delegated authorization. This model allows a third-party application to access resources on a user's behalf without ever seeing their actual password. The password grant actively breaks this delegation model. By requiring the user to type their username and password directly into the client application, we train users to hand their sensitive credentials to third parties. Even in first-party scenarios where your organization owns both the frontend and the backend, handling raw credentials in the client application expands your attack surface unnecessarily.

Furthermore, this flow severely limits your ability to enforce modern identity security features. Because the client application manages the login form, introducing multi-factor authentication (MFA), CAPTCHAs, or federated single sign-on (SSO) becomes complex or technically unfeasible. The authorization server has no control over the login experience, which makes the password grant a rigid and insecure choice for modern applications.

Migration strategies for modern architectures

Modern Spring Authorization Server implementations do not support the password grant out of the box, which reflects current industry best practices. When tasked with migrating an existing system off the password grant, your replacement strategy depends entirely on the type of client making the request.

The following table outlines the standard migration paths for legacy applications.

By adopting these modern alternatives, you ensure the authorization server retains full control over the authentication process, enabling advanced security features like MFA without changing the client code.

To confirm our understanding of these architectural shifts, let’s evaluate the core vulnerability we are designing away from.

Understanding why the password grant fails modern security standards provides the necessary context for why modern Spring Security architectures mandate flows that safely separate authentication from the client application.