[keycloak-dev] OAuth2 Incremental Authorization

[Pedro Igor Silva]

On Wed, Apr 25, 2018 at 10:31 AM, Pedro Igor Silva <psilva at redhat.com>
wrote:

> 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).
>

In fact you should be able to have different audiences depending on the
scopes you ask. But it is not suitable for using token types other than
regular urn:ietf:params:oauth:token-type:access_token or obtaining a token
for delegation. Maybe impersonation at a certain degree as the client is
still acting on user behalf. But with incremental authorization the client
to which the token was issued for is always the same.


>
> 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
>>
>
>