[keycloak-dev] OAuth2 Incremental Authorization
Bill Burke
bburke at redhat.com
Wed Apr 25 10:54:52 EDT 2018
FYI, at least in master you can do a "poor man's" step up
authentication as you can define and override authentication flows per
client. A more structured and formal way of doing this would be 100
times better though.
On Wed, Apr 25, 2018 at 10:01 AM, Youssef EL HOUTI
<youssef.elhouti at gmail.com> wrote:
> Many issues have been opened previously about step up/adaptive
> authentication, with the idea to trigger Authentication Steps only if a
> Level of security is required (with security levels mapped to scopes...),
> IMO this could be a good time to implement the two.
>
> On Wed, Apr 25, 2018 at 3:31 PM, 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).
>>
>> 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
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
--
Bill Burke
Red Hat
More information about the keycloak-dev
mailing list