Re: [keycloak-user] (no subject)

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(a)redhat.com <mailto: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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user