What the configuration of spring-security-oauth2 authorizedGrantTypes means in practice?

Question

For example on the default jhipster UAA configuration we have:

clients.inMemory() .withClient("web_app") .scopes("openid") .autoApprove(true) .authorizedGrantTypes("implicit","refresh_token", "password", "authorization_code") .and() .withClient(jHipsterProperties.getSecurity() .getClientAuthorization().getClientId()) .secret(jHipsterProperties.getSecurity() .getClientAuthorization().getClientSecret()) .scopes("web-app") .autoApprove(true) .authorizedGrantTypes("client_credentials");

So what does "authorizedGrantTypes" really means in practice? The first client "web_app" will have different types including refresh and so the second will be able to generate a token as client_credentials. What is the difference?

Another question, what is the purpose of the second client authentication which uses "client_credentials" ? Since this is disconnected from the real users stored. microservice to microservice communication? Looks bad if the configuration is deployed on spring cloud (client and secret hard coded configuration) to allow any external authentication via the gateway. How to prevent this?

Answer 1

OAuth 2.0 grant types are the different "ways" your client applications can obtain tokens.

There are a bunch of articles explaining it better, but here is a summary :

• authorization_code is the "classic" OAuth 2.0 flow, where the user is asked for its consent through redirections. The client application is strongly authenticated because it has to send all its credentials (client_id+ client_secret + redirect_uri) before it can get a token.
• implicit is almost the same as authorization_code, but for public clients (web apps or installed/mobile applications). The flow is almost the same from the user standpoint, but with weaker client authentication. The redirect_uri is the only security, as the client receives the access token through redirection + request parameters.
• password is straight forward : the client application collects the user credentials, and sends both the user credentials (username+password) and its own credentials (client_id+client_secret) in exchange for a token. This flow mixes authorization with authentication, and should only be used when there is no other choice (i.e. your own installed/mobile application, where you don't want users to switch back and forth between native app and browser). You should never allow a third party to use this flow.

With all these flows, the user is asked for its permission, one way or another. The token given to the client allows it only to access that single user's data.

The client_credentials grant is different, as it does not involve a user. It is a drop in replacement for HTTP Basic.
Instead of sending a username (client_id) + password (client_secret) for every request, your client sends its credentials in exchange for a token.

It is used in server-to-server communications, where you want to know "which application is calling" by giving it distinct credentials, but you don't tie its authorization with a specific user.

Some examples :

• a command line application (batch) or worker process consuming secured services. This kind of application probably processes a bunch of user data at once, and it cannot request each user's consent. The service called has to know "who" is calling in order to allow the client application to access anything.
• a third party / external client of your API wants to know informations that are not linked to user data (for example : usage stats, quotas, billing...)
• a third party / external client with special privileges who can access all your users' data

---

Note : In service to service communication, you should relay the token received from the outside instead of having each intermediate application request its own token.