[keycloak-user] (no subject)

[Corinne Krych]

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141016/9463baab/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20141016/9463baab/attachment.bin