[keycloak-user] (no subject)

[Bill Burke]

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

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com