The widely used password mode of OAuth2.0 has been abandoned, give it up

Recently, some students have been asking why OAuth2 password mode Spring Security has not been implemented, even the new Spring Authorization Server has no such thing.

In fact, I can tell you here that the OAuth2 password mode is abolished, and the OAuth2 Security Guide related chapters. In the future, the new OAuth2 implementation is unlikely to actively adapt to this mode. Well-known products such as Auth0 , JIRA have removed this mode in production. It works so well why remove it? The fat brother found some information, roughly a few points.

OAuth2 is an authorization framework

OAuth2 itself is an authorization framework, it does not define the user authentication process. Its original intention is to solve the problem of authorized access between different services, it can't make it clear that you think the correct receiver is that receiver. Currently, only the extended protocol OIDC 1.0 of OAuth2 has the user authentication function.

Cipher mode is more like a compatibility protocol

When the password mode was born, single-page applications such as React , Vue hadn't yet emerged, not even the framework. It's more of a transition solution to address legacy issues. In traditional applications, users are accustomed to handing the password directly to the client in exchange for resource access rights, rather than jumping around to pull authorization and confirm authorization. OAuth2 born, it was designed to allow users to slowly change from traditional thinking.

This mode works well, but it breaks the delegated authorization mode and reduces the security of OAuth2 .

The flow is very much like a "phishing attack", imagine an app randomly letting you enter your password for one platform in the login page of the other, which is fine if both platforms are trusted. But is it really believable? No one dared to make a ticket.

For security, this expands the area of password exposure, and passwords are always prompted to keep them carefully to avoid leakage. This is an anti-password mode. User passwords may have been leaked in this link intentionally or unintentionally. Moreover, the user cannot control the scope of authorization. Although the user restricts scope , the client program still provides programming opportunities to break the user's scope . If you use password mode on the public OAuth2 client, your token endpoint may also be sniffed and brute force exhausted.

Therefore, in OAuth2 best practice has explicitly required that this mode cannot be used, and even used the MUST NOT BE in the statement.

What are the alternatives?

In OAuth2.1 , there are only these three

• Authorization Code + PKCE Use this mode if you need secure authorization.
• Client Credentials If your client needs to interact with other clients, please use this mode
• Device Code If you are developing IoT application and want to use OAuth2 , you can consider this mode.

In comparison, OAuth2.1 is more security-focused and is currently being drafted.

What if I still need user authentication? Currently only OIDC 1.0 available. So fellow students, the future direction should be clear, the password mode should be abandoned.

Follow the official account: Felordcn for more information

Personal blog: https://felord.cn