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.

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

From: "Corinne Krych" <corinnekrych(a)gmail.com&gt; To: "Bill Burke" <bburke(a)redhat.com&gt; Cc: keycloak-user(a)lists.jboss.org Sent: Thursday, 16 October, 2014 8:54:15 PM Subject: Re: [keycloak-user] (no subject) I missed the “direct grants only OAuth client” mentioned in original mail. Isn’t a direct grant oauth client as trusted as application? ++ Corinne On 16 Oct 2014, at 20:04, Bill Burke <bburke(a)redhat.com&gt; wrote: > Applications are "trusted" in Keycloak and don't require the consent > screen. So, I think we should allow roles to be updated on a request. > > On 10/16/2014 1:47 PM, Corinne Krych wrote: >> 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 >> > > -- > 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