what's the alternative to password grant now that it is deprecated? OAUTH 2.0

Question

• I have a rest api built in spring boot.
  • A front end application in react.

I have users who should be able to log in and access their information e.g. orders. now in order for users to log in and register I thought it would be a best idea to use OAUTH. I started my research into ouath and found grant password be the perfect case. since the user be able to type in the their credentials (username and password) which goes to api service (also authorisation server) and that can authenticate and token will be passed but then I realised it is deprecated so I want to know whats the best grant type to use where user's username and password is passed for authentication and authorisation. or maybe i am missing something very simple that you guys can point towards.

Answer 1

To summarize your situation: You have your own backend (server of some kind, such as a web application implementing a REST API) where users should be able to login using a username and password to obtain an access token giving their access to their own resources on the server, and they should be able to do this through your own frontend (client of some kind, such as smartphone app, desktop app, single-page application, etc.). The Resource Owner Password Grant solved your problem perfectly fine, but now it got deprecated :(

Note
It says in the OAuth 2.0 spec that The OAuth 2.0 authorization framework enables a third-party application to obtain limited access [...]. Your frontend is not really a third-party application in this case, but a first-party application, so you shouldn't really use OAuth 2.0, but it's better to use something well-documented instead of inventing your own solution to handle authorization, so just as you, I would still use OAuth 2.0.

Simple solution (deprecated)
Continue using Resource Owner Password Grant. It does precisely what you want, and it was created for your specific case (frontend and backend come from the same "company").

Now they seem to have decided that OAuth 2.1 should not support first-party applications like this, but I would say it's still fine to use it for your case. It would be much worse if Google or someone else big OAuth 2.0 provider would support this Grant Type, because then developers might create their own frontend applications and let users login in on their frontend application by entering their Google username and password directly into the frontend application, i.e. revealing their Google credentials to the frontend developer. I imagine the reason they deprecate this Grant Type is to avoid such situations.

Better solution (deprecated)
Use Implicit Grant. In the frontend, when the user wants to login, redirect the user to the backend (i.e. open a webpage on the backend with a login form where the user can enter username and password), and after the user has successfully logged in on the backend, redirect the client back to the frontend with the access token. The benefit here is that the user only reveals her password to the backend application, and never to any client application. The drawback is that the backend must contain a webpage for the login form, making it a bit more complicated to implement compared to a pure REST API. And if you want to do this properly, the server should have a list of pre-registered clients with ids and secrets, but if you only have your own frontend you need to support I would say you can skip that or simply hardcode a client id in the backend application.

Unfortunately, this grant type has been deprecated as well...

Proper solution
Use Authorization Code Grant (with Proof Key for Code Exchange). This way is really similar to the Implicit Grant described above, but instead of redirecting the user back to the frontend with the Access Token, you redirect the user back to the frontend with an Authorization Code. The frontend can then send this Authorization Code to the backend and get back the Access Token.

What was described above was more or less only Authorization Code Grant. "with Proof Key for Code Exchange" is pretty much the same, but you also use a "key" to prove that you are the same client that redirects that user to the backend as and that trades the Authorization Code for an Access Token (the "with Proof Key for Code Exchange" part basically makes it more secure).

---

Here I've of course only described the overall idea, you need to look into the specifications to learn the details about the requests and responses you should send (what the body of the request should be, what status codes that are used, etc.).

Answer 2

OAuth is specifically designed for delegated authorization, that is, authorization to access a resource on behalf of the user. It is not designed for authentication. OpenID Connect (built-on top of OAuth) is designed for authentication.

In a delegated authentication/authorization environment, the authentication/authorization tasks are performed by specific independent services. If your application also manages authentication/authorization, maybe you don't need OpenID Connect/OAuth.

Anyway, the Resource Owner Password Grant is the worst delegated OAuth flow. It should be used in very rare legacy cases, and it is deprecated in OAuth2.1. See this article for more details.

The OAuth flow to use mostly depends on your application architecture. Take a look here to determine which flow better fits your needs.