What is the spring-security-oauth2 authorGrantTypes configuration in practice?
For example, with the default setting for jipster UAA, 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" mean in practice? The first client "web_app" will be of different types including update and hence 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 that uses "client_credentials"? Since this is disconnected from real users. microservice to microservice communication? It looks like if the config is deployed in spring cloud (client and secret hardcoded config) to allow any external authentication through the gateway. How can this be prevented?
source to share
OAuth 2.0 grant types are different "ways" your client applications can receive tokens.
There are tons of articles out there explaining this better , but here's a summary:
-
authorization_code
is the "classic" OAuth 2.0 flow in which the user is prompted for their consent through a redirect. The client application is strongly authenticated as it must send all of its credentials (client_id
+client_secret
+redirect_uri
) before it can receive the token. -
implicit
almost the same as authorization_code, but for public clients (web apps or installed / mobile apps). The flow is almost the same from the user's point of view, but with weaker client authentication.redirect_uri
is the only protection, as the client receives the access token via the redirect + request parameters. -
password
straight forward: the client app collects the user's credentials and sends both the user's 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 app where you don't want users to switch between native app and browser). You should never allow a third party to use this stream.
With all these flows, the user asks for his permission one way or another. The token provided to the client allows him to access only the data of one user.
The grant client_credentials
is different as it is not associated with a user. It is a replacement for HTTP Basic. Instead of sending username ( client_id
) + password ( client_secret
) for each request, your client sends their credentials in exchange for a token.
It is used in server-to-server communications where you want to know "which application is calling" by providing it with different credentials, but you do not bind its authorization to a specific user.
Some examples:
- a command line application (batch) or a workflow that consumes protected services. Such an application is likely to process multiple user data at once and cannot ask for every user's consent. The service call needs to know "who" is calling so that the client application can access anything.
- a third party / external client of your API wants to know information not related to user data (for example: usage statistics, quotas, billing ...)
- third party / external client with special privileges that can access all your users data.
Note. When serving service communication, you should pass the token received from the outside, instead of each middleware requesting its own token.
source to share