<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hello Alarik,</div><div><br></div>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:<div><div><a href="http://tools.ietf.org/html/rfc6749#section-1.5">http://tools.ietf.org/html/rfc6749#section-1.5</a></div><div><br></div><div> refresh tokens are issued to the client by the authorization server and are</div><div> used to obtain a new access token when the current access token</div><div> becomes invalid or expires, or to obtain additional access tokens</div><div> <b>with identical or narrower scope</b> (access tokens may have a shorter</div><div> lifetime and fewer permissions than authorized by the resource</div><div> owner). </div><div><br></div><div>Some how makes sense to have to approved the new grants.</div>I need to check how it behaves with OAuth2 providers like Google
</div><div> <br>++<div>Corinne</div><div></div><div>AeroGear iOS team</div><div><br><div>On 16 Oct 2014, at 19:17, Bill Burke <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>> wrote:<br><br><blockquote type="cite"><br><br>On 10/16/2014 12:50 PM, Alarik Myrin wrote:<br><blockquote type="cite">I am having a strange situation, which might be arising from a bug in<br>Keycloak.<br><br>I have a direct grants only OAuth client which makes invocations against<br>a bearer-only REST interface, running on Wildfly 8.0.0 Final with<br>Keycloak 1.0 final.<br><br>A side effect of making one of the invocations is that the user is added<br>to a realm role. So far so good. The access token used to make that<br>invocation though does not contain the new realm role so he cannot, yet,<br>make invocations against another endpoint (call it endpoint B) without<br>getting a 403 Forbidden. This is expected.<br><br>So, the client has to refresh the access token<br>(realms/{realm}/tokens/refresh), in order to get a new access token with<br>the realm role. The refresh goes OK, but when he tries to make<br>invocations against endpoint B, he still gets a 403 Forbidden.<br><br></blockquote><br>Keycloak will only populate the refreshed token with the original <br>granted roles. The idea is that there may have been consent involved <br>and the user can't consent to any newly added roles.<br><br>I guess we could change it in that if the client is an application and <br>not an oauth client, it would get the new roles.<br><br>-- <br>Bill Burke<br>JBoss, a division of Red Hat<br><a href="http://bill.burkecentral.com">http://bill.burkecentral.com</a><br>_______________________________________________<br>keycloak-user mailing list<br>keycloak-user@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/keycloak-user<br></blockquote><br></div></div></div></body></html>