Jmix 2.0 REST clients with username + password authentication

Support
#1

Hello, so ok, I somewhat get it - with the new spring security missing the password grant type it got a lot more complicated :see_no_evil:

So if I want to implement a e.g. react client, I would have to call the oauth2/authorize endpoint, be forwarded to a Jmix login page and then transform the response and call the oauth2/token endpoint where I get a token that I can use to authenticate my REST calls with, right?

If this is correct, my question is: shouldn’t that be easier? :smiley: I mean, I actually want my login page to be in the client app of course. So I would have a request where I provide username + password - as it used to be before. And then ideally some endpoint would return me the access token - as it used to be before. :smiley:

Why did this change so much? Can we implement an endpoint that will have a similar easy handling as before?

#3

Hello,

The old method of authentication by username and password is currently outdated and is not recommended for use. More details here.

The Password grant type is a legacy way to exchange a user’s credentials for an access token. Because the client application has to collect the user’s password and send it to the authorization server, it is not recommended that this grant be used at all anymore.

But you can implement your own authentication mechanism.

Forum: Custom Authentication tip from cuba does not work in jmix
Issuer: Obtain access token programmatically · Issue #136 · jmix-projects/jmix-security · GitHub

Regards,
Nikita

#5

Thank you. I’m still trying to fully understand this decision (I get that this was not Jmix’s decision) though. Maybe you can help me. I get that oauth was actually developed to actually prevent the authorization to the application directly and use an authorization server. So the new way of doing this should always redirect to a login page of the authorization server directly?

And the reason is, to mitigate risks with bugs or security issues in custom login pages?

This makes the most sense to me when the authorization server is different from the resource server, but in the case of Jmix, the auth server = the resource server.

Thanks for the links, but in the case of spring security 6 this doesn’t work this way anymore.

#7

Hello,

Yes, this method redirects to the login page of the authorization server. The main reason for the approach is that the client application does not collect user passwords.

Some more additional information:

Yes, this is convenient when there are two servers: an authorization server and a resource server.

But in Jmix, you can use one server for authorization and provision of data, or split them into two, and make your own SSO on Jmix.

Additionally:
Always going to the login page to get a token is not always convenient, for example, in the case of integration. Therefore, you can use a simplified way to get a token for certain clients: https://github.com/jmix-framework/jmix/tree/master/jmix-authserver#client-credentials-grant-type

Regards,
Nikita

#9

For those who are interested in implementing a frontend with OAuth2 Authorization Code grant - there is an example in the GitHub - jmix-framework/jmix-samples-2: Examples of solving typical problems in Jmix applications repository.

1 Like