Re: [keycloak-user] (no subject)

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