Mixing
Refresh token with Keycloak
up vote
1
down vote
favorite
I use JWT for Client Authentication in Keycloak:
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
client-assertion-type%3Ajwt-bearer&
client_assertion=eyJhbGciOiJSUzI1NiJ9.
eyJpc3Mi[...omitted for brevity...].
cC4hiUPo[...omitted for brevity...]
I get :
assess_token
refresh_token
token_type
expires_in
When I try to refresh token I send refresh_token itself, grant type refresh_token and get:
{
"error": "unauthorized_client",
"error_description": "INVALID_CREDENTIALS: Invalid client credentials"
}
when I specify client_id I get:
{
"error": "invalid_client",
"error_description": "Parameter client_assertion_type is missing"
}
If I specify client_assertion_type I get error that client_assertion itself is missing, so I literally have to provide parameters I provided when retrieved access token.
How that refreshing process actually should work?
oauth-2.0 keyboard openid openid-connect
asked yesterday
Sergii Getman
1,59011731
add a comment |
up vote
1
down vote
favorite
I use JWT for Client Authentication in Keycloak:
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
client-assertion-type%3Ajwt-bearer&
client_assertion=eyJhbGciOiJSUzI1NiJ9.
eyJpc3Mi[...omitted for brevity...].
cC4hiUPo[...omitted for brevity...]
I get :
assess_token
refresh_token
token_type
expires_in
When I try to refresh token I send refresh_token itself, grant type refresh_token and get:
{
"error": "unauthorized_client",
"error_description": "INVALID_CREDENTIALS: Invalid client credentials"
}
when I specify client_id I get:
{
"error": "invalid_client",
"error_description": "Parameter client_assertion_type is missing"
}
If I specify client_assertion_type I get error that client_assertion itself is missing, so I literally have to provide parameters I provided when retrieved access token.
How that refreshing process actually should work?
oauth-2.0 keyboard openid openid-connect
asked yesterday
Sergii Getman
1,59011731
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I use JWT for Client Authentication in Keycloak:
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
client-assertion-type%3Ajwt-bearer&
client_assertion=eyJhbGciOiJSUzI1NiJ9.
eyJpc3Mi[...omitted for brevity...].
cC4hiUPo[...omitted for brevity...]
I get :
assess_token
refresh_token
token_type
expires_in
When I try to refresh token I send refresh_token itself, grant type refresh_token and get:
{
"error": "unauthorized_client",
"error_description": "INVALID_CREDENTIALS: Invalid client credentials"
}
when I specify client_id I get:
{
"error": "invalid_client",
"error_description": "Parameter client_assertion_type is missing"
}
If I specify client_assertion_type I get error that client_assertion itself is missing, so I literally have to provide parameters I provided when retrieved access token.
How that refreshing process actually should work?
oauth-2.0 keyboard openid openid-connect
asked yesterday
Sergii Getman
1,59011731
I use JWT for Client Authentication in Keycloak:
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
client-assertion-type%3Ajwt-bearer&
client_assertion=eyJhbGciOiJSUzI1NiJ9.
eyJpc3Mi[...omitted for brevity...].
cC4hiUPo[...omitted for brevity...]
I get :
assess_token
refresh_token
token_type
expires_in
When I try to refresh token I send refresh_token itself, grant type refresh_token and get:
{
"error": "unauthorized_client",
"error_description": "INVALID_CREDENTIALS: Invalid client credentials"
}
when I specify client_id I get:
{
"error": "invalid_client",
"error_description": "Parameter client_assertion_type is missing"
}
If I specify client_assertion_type I get error that client_assertion itself is missing, so I literally have to provide parameters I provided when retrieved access token.
How that refreshing process actually should work?
oauth-2.0 keyboard openid openid-connect
oauth-2.0 keyboard openid openid-connect
asked yesterday
Sergii Getman
1,59011731
asked yesterday
Sergii Getman
1,59011731
asked yesterday
Sergii Getman
1,59011731
asked yesterday
Sergii Getman
1,59011731
asked yesterday
Sergii Getman
1,59011731
1,59011731
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
This could very well be a limitation or policy defined by Keycloak. RFC7523 (JWT for Client Authentication) does allow to enable client credentials when JWT authentication is present. This is highlighted from 3.1. Authorization Grant Processing
JWT authorization grants may be used with or without client
authentication or identification. Whether or not client
authentication is needed in conjunction with a JWT authorization
grant, as well as the supported types of client authentication, are
policy decisions at the discretion of the authorization server.
However, if client credentials are present in the request, the
authorization server MUST validate them.
So even if Keycloak support JWT client authentication, it may still require client credentials to be present in the refresh token request. But also, it could be a limitation from their end.
Additionally, token refresh is defined through RFC6749 - The OAuth 2.0 Authorization Framework. According to it's section 6, refresh token request must contain client credentials when client is a confidential client (simply a client which was created with id and a password). If what you seen is not a limitation, then guess Keycloak adhere to RFC6749 and require you to send client credentials in token refresh request.
answered yesterday
Kavindu Dodanduwa
5,42111230
1
yes, unfortunately client type is confidential and force us sending all creds. thanks a lot!
– Sergii Getman
yesterday
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
This could very well be a limitation or policy defined by Keycloak. RFC7523 (JWT for Client Authentication) does allow to enable client credentials when JWT authentication is present. This is highlighted from 3.1. Authorization Grant Processing
JWT authorization grants may be used with or without client
authentication or identification. Whether or not client
authentication is needed in conjunction with a JWT authorization
grant, as well as the supported types of client authentication, are
policy decisions at the discretion of the authorization server.
However, if client credentials are present in the request, the
authorization server MUST validate them.
So even if Keycloak support JWT client authentication, it may still require client credentials to be present in the refresh token request. But also, it could be a limitation from their end.
Additionally, token refresh is defined through RFC6749 - The OAuth 2.0 Authorization Framework. According to it's section 6, refresh token request must contain client credentials when client is a confidential client (simply a client which was created with id and a password). If what you seen is not a limitation, then guess Keycloak adhere to RFC6749 and require you to send client credentials in token refresh request.
answered yesterday
Kavindu Dodanduwa
5,42111230
1
yes, unfortunately client type is confidential and force us sending all creds. thanks a lot!
– Sergii Getman
yesterday
add a comment |
up vote
1
down vote
accepted
This could very well be a limitation or policy defined by Keycloak. RFC7523 (JWT for Client Authentication) does allow to enable client credentials when JWT authentication is present. This is highlighted from 3.1. Authorization Grant Processing
JWT authorization grants may be used with or without client
authentication or identification. Whether or not client
authentication is needed in conjunction with a JWT authorization
grant, as well as the supported types of client authentication, are
policy decisions at the discretion of the authorization server.
However, if client credentials are present in the request, the
authorization server MUST validate them.
So even if Keycloak support JWT client authentication, it may still require client credentials to be present in the refresh token request. But also, it could be a limitation from their end.
Additionally, token refresh is defined through RFC6749 - The OAuth 2.0 Authorization Framework. According to it's section 6, refresh token request must contain client credentials when client is a confidential client (simply a client which was created with id and a password). If what you seen is not a limitation, then guess Keycloak adhere to RFC6749 and require you to send client credentials in token refresh request.
answered yesterday
Kavindu Dodanduwa
5,42111230
1
yes, unfortunately client type is confidential and force us sending all creds. thanks a lot!
– Sergii Getman
yesterday
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
This could very well be a limitation or policy defined by Keycloak. RFC7523 (JWT for Client Authentication) does allow to enable client credentials when JWT authentication is present. This is highlighted from 3.1. Authorization Grant Processing
JWT authorization grants may be used with or without client
authentication or identification. Whether or not client
authentication is needed in conjunction with a JWT authorization
grant, as well as the supported types of client authentication, are
policy decisions at the discretion of the authorization server.
However, if client credentials are present in the request, the
authorization server MUST validate them.
So even if Keycloak support JWT client authentication, it may still require client credentials to be present in the refresh token request. But also, it could be a limitation from their end.
Additionally, token refresh is defined through RFC6749 - The OAuth 2.0 Authorization Framework. According to it's section 6, refresh token request must contain client credentials when client is a confidential client (simply a client which was created with id and a password). If what you seen is not a limitation, then guess Keycloak adhere to RFC6749 and require you to send client credentials in token refresh request.
answered yesterday
Kavindu Dodanduwa
5,42111230
This could very well be a limitation or policy defined by Keycloak. RFC7523 (JWT for Client Authentication) does allow to enable client credentials when JWT authentication is present. This is highlighted from 3.1. Authorization Grant Processing
JWT authorization grants may be used with or without client
authentication or identification. Whether or not client
authentication is needed in conjunction with a JWT authorization
grant, as well as the supported types of client authentication, are
policy decisions at the discretion of the authorization server.
However, if client credentials are present in the request, the
authorization server MUST validate them.
So even if Keycloak support JWT client authentication, it may still require client credentials to be present in the refresh token request. But also, it could be a limitation from their end.
Additionally, token refresh is defined through RFC6749 - The OAuth 2.0 Authorization Framework. According to it's section 6, refresh token request must contain client credentials when client is a confidential client (simply a client which was created with id and a password). If what you seen is not a limitation, then guess Keycloak adhere to RFC6749 and require you to send client credentials in token refresh request.
answered yesterday
Kavindu Dodanduwa
5,42111230
edited yesterday
answered yesterday
Kavindu Dodanduwa
5,42111230
answered yesterday
Kavindu Dodanduwa
5,42111230
answered yesterday
Kavindu Dodanduwa
5,42111230
5,42111230
1
yes, unfortunately client type is confidential and force us sending all creds. thanks a lot!
– Sergii Getman
yesterday
add a comment |
1
yes, unfortunately client type is confidential and force us sending all creds. thanks a lot!
– Sergii Getman
yesterday
1
1
yes, unfortunately client type is confidential and force us sending all creds. thanks a lot!
– Sergii Getman
yesterday
yes, unfortunately client type is confidential and force us sending all creds. thanks a lot!
– Sergii Getman
yesterday
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53372454%2frefresh-token-with-keycloak%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
