[keycloak-dev] OAuth2 Incremental Authorization

[Pedro Igor Silva]

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 at 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 at 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 at 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 at 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 at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> Bill Burke
> Red Hat
>