A long time ago I discussed this with Marek (IIRC).
Currently, every time you obtain a token from the token endpoint a new
session is created. I personally don't think we should do that but reuse
the client session, at least. If that is the case, we don't even need a
refresh token too, given that the client is acting on its own behalf and it
can always obtain a new token using his credentials.
The `SHOULD_NOT` in that part of the spec does not mean it is wrong to
return a refresh token (as per RFC-2119) though. But yeah, more/unnecessary
steps for the client. For now, I would suggest using the RT to avoid
sessions from being created.
Regards.
Pedro Igor
On Thu, Oct 31, 2019 at 7:04 AM Sebastian Rus <russebastian.ui(a)gmail.com>
wrote:
Hi,
I have created a client with 'confidential' Access Type for a microservice
which has to connect to other keycloak secured microservice. I enabled
"Service Accounts Enabled" option, which "[...] in terms of OAuth2
specification, enables support of Client Credentials Grant for client".
Everything seemed to be OK, until I saw a huge number of sessions for that
client. It turned out that that the token endpoint returns a refresh token.
A request interceptor I use in my microservice application just ignores the
refresh token and uses client credentials to obtain the new one - which
creates a new session every time new access token is issued.
Oauth2 specification (
https://tools.ietf.org/html/rfc6749#section-4.4.2)
says that "A refresh token SHOULD NOT be included" for client_credentials
grant type. So why is it included? Is the presence of refresh token
configurable for 'confidential' Access Type and client_credentials grant?
Best regards,
Sebastian
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user