[keycloak-user] Refresh token in client_credentials grant type
Pedro Igor Silva
psilva at redhat.com
Thu Oct 31 11:02:36 EDT 2019
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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
More information about the keycloak-user
mailing list