I'm not sure if the spec is redundant because of token exchange. Token
exchange aims a different use case and this stuff is just about incremental
authorization and granting scopes on demand. AFAIK, there is no change of
audience as it is all about an existing session (in case of public clients
+ refresh token) or previously granted scopes (in case of confidential
clients + client credentials).
Yeah, it is interesting. I think they are using a refresh token in order to
make sure client is obtaining tokens within the same session.
On Wed, Apr 25, 2018 at 10:05 AM, Bill Burke <bburke(a)redhat.com> wrote:
I'll ping the OAuth WG, but, its kind of redundant with token
exchange. Unless client requires consent, not sure why this option
would be used. Interesting that they require refresh token as a
credential for public clients though.
On Wed, Apr 25, 2018 at 7:50 AM, Pedro Igor Silva <psilva(a)redhat.com>
wrote:
> Yeah, I agree it should be the same authentication session. And that spec
> can be a good reference to make sure we are doing it correctly or at
least
> based on other experiences around this requirement.
>
> >From what I have seen in oauth2 mailing list, people there are willing
to
> make it a standard.
>
> On Wed, Apr 25, 2018 at 4:13 AM, Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>
>> Haven't read that spec yet. With Marek's work it should be possible for
a
>> client to request additional scopes by redirecting to login screen
again,
>> but there's probably more to it than that. One thing that at least
comes to
>> mind is that it should be the same authentication session.
>>
>> On 24 April 2018 at 14:41, Pedro Igor Silva <psilva(a)redhat.com> wrote:
>>
>>> Hi,
>>>
>>> I think this is related with what we discussed in our last meeting
>>> regarding scopes.
>>>
>>> See
https://datatracker.ietf.org/doc/draft-wdenniss-oauth-increm
>>> ental-auth/.
>>>
>>> We have that in AuthZ Services, but this should be pure OAuth2.
>>>
>>> Regards.
>>> Pedro Igor
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
Red Hat