Hello Alarik,

Interesting use case, I would I thought like you that the newly refreshed access token would contain the new role grant, but reading the spec:
http://tools.ietf.org/html/rfc6749#section-1.5

   refresh tokens are issued to the client by the authorization server and are
   used to obtain a new access token when the current access token
   becomes invalid or expires, or to obtain additional access tokens
   with identical or narrower scope (access tokens may have a shorter
   lifetime and fewer permissions than authorized by the resource
   owner). 

Some how makes sense to have to approved the new grants.
I need to check how it behaves with OAuth2 providers like Google…
 
++
Corinne
——————
AeroGear iOS team

On 16 Oct 2014, at 19:17, Bill Burke <bburke@redhat.com> wrote:



On 10/16/2014 12:50 PM, Alarik Myrin wrote:
I am having a strange situation, which might be arising from a bug in
Keycloak.

I have a direct grants only OAuth client which makes invocations against
a bearer-only REST interface, running on Wildfly 8.0.0 Final with
Keycloak 1.0 final.

A side effect of making one of the invocations is that the user is added
to a realm role. So far so good.  The access token used to make that
invocation though does not contain the new realm role so he cannot, yet,
make invocations against another endpoint (call it endpoint B) without
getting a 403 Forbidden. This is expected.

So, the client has to refresh the access token
(realms/{realm}/tokens/refresh), in order to get a new access token with
the realm role.  The refresh goes OK, but when he tries to make
invocations against endpoint B, he still gets a 403 Forbidden.


Keycloak will only populate the refreshed token with the original 
granted roles.  The idea is that there may have been consent involved 
and the user can't consent to any newly added roles.

I guess we could change it in that if the client is an application and 
not an oauth client, it would get the new roles.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user