OAuth2: resource-server / client

[pascalgrimaud]

• following https://github.com/jhipster/jhipster-lite/pull/443

Currently, the API OAuth2 generates:

• client - https://www.baeldung.com/spring-security-5-oauth2-login
• resource-server - https://www.baeldung.com/spring-security-oauth-resource-server

After some discussion with @Bolo89 and following this very important comment https://github.com/jhipster/jhipster-lite/issues/270#issuecomment-1014090299 too, let's discuss about how to have a better minimal option for microservice (for example)

cc @Bolo89 @pblanchardie

[pblanchardie]

For user-facing monoliths without reusable APIs, a better minimal option would be "login-only" (without resource server). It was the first version of the previous PR, so it would be easy to reproduce.

Microservices and standard Web Services should not provide "login" but only JWT, so SecurityConfiguration should override the default configuration without oauth2Login(). See https://www.baeldung.com/spring-webclient-oauth2#avoiding-oauth2login

"login" must not be confused with "client":

• oauth2Login() provides the OAuth2 login feature for end-users interacting with the application
• oauth2Client() is used for machine-to-machine communications, with eg. WebClient

So there is another case, which is "client-only" for a job that calls APIs but doesn't not expose anything. It's a less common scenario, and although I implemented it in a previous attempt, I guess it won't be very useful.

Do you confirm that we prefer distinct endpoints over common endpoints with options?

[pascalgrimaud]

Thanks for clarification @pblanchardie

Indeed you're right about oauth2Login(), see the generator-jhipster:

• monolith
• reactive

I'll see how to propose something smarter, with your initial idea. Maybe 2 versions of OAuth2:

• one with login (generally, used with a front): probably the default one
• one without login

About endpoints, yes, for now, I prefer distinct endpoints, until this ticket is solved: https://github.com/jhipster/jhipster-lite/issues/144 Then, it can be changed later, during refactoring if needed.

[pascalgrimaud]

The new module OAuth2 is better now, thanks to @DamnClin So this ticket can be closed, if there are some suggestions, we can open a new ticket to discuss