[keycloak-user] (no subject)

[Corinne Krych]

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

-------------- 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/073d8cb3/attachment.bin