[keycloak-user] (no subject)

[Stian Thorgersen]

Makes sense to add new roles granted to the user. I don't think we should add more roles if added to the scope of the application. Also, in the future if/when we add support for scope query param, we need to remember that so we don't add roles the application didn't request. This would also fix the similar issue we have with the admin console, and allow us to use the token directly instead of whoAmI to get permitted roles.

What should happen if a role is removed from the user? For consistency it should just remove the role from the token, but if an application doesn't recheck the roles in the refreshed token it may potentially miss the revocation of the role and still provide access to it.

----- Original Message -----
> From: "Corinne Krych" <corinnekrych at gmail.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-user at 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 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
> 
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user