8:41 a.m.
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-incremental-auth/.
We have that in AuthZ Services, but this should be pure OAuth2.
Regards.
Pedro Igor
3:13 a.m.
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-
incremental-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
7:50 a.m.
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
>
9:05 a.m.
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
9:31 a.m.
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
10:01 a.m.
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(a)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(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
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:45 a.m.
Adaptive authentication is a separated beast though as it may also
be related to risk-based authentication/authorization. Some form of
calculation based on different sources of information to obtain some score
to then take some action. It is a hell of a feature depending on how much
we want to invest in it.
On Wed, Apr 25, 2018 at 11:01 AM, Youssef EL HOUTI <
youssef.elhouti(a)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(a)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(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
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
11:06 a.m.
On Wed, Apr 25, 2018 at 10:45 AM, Pedro Igor Silva <psilva(a)redhat.com> wrote:
Adaptive authentication is a separated beast though as it may also
be
related to risk-based authentication/authorization. Some form of calculation
based on different sources of information to obtain some score to then take
some action. It is a hell of a feature depending on how much we want to
invest in it.
Lol, that *WOULD* be cool......I always worried that step-up
authentication would be an edge case as most customers/users would
want to require 2nd factor authentication up front. Would a more
common case be that a certain client scope requires re-authentication?
i.e. to perform a sensitive operation? FYI, I'm completely
speculating here.
--
Bill Burke
Red Hat
11:24 a.m.
Yeah, I believe so but we could also think about something slightly more
complete/complex ... Like Youseff mentioned, the concept of security levels
could also be an option for something more richer and flexible. For
instance, we could have some way to allow users to:
* Create a security level
* Define what a security level means. For instance, it requires
authentication method X, claims A, B, C. Where claims can be anything, from
user's location to the network he is using.
* Define actions that should be taken in order to gain a security level.
For instance, ask for authentication method X, show a page to provide
arbitrary information.
Then based on the security level check for scopes that require a specific
security level or even allow applications to perform validations based on
the security level available from the token. We would also allow client
applications to redirect the user to Keycloak in order to start a "raise
your level" flow, etc ...
FYI, I'm also completely speculating here :)
On Wed, Apr 25, 2018 at 12:06 PM, Bill Burke <bburke(a)redhat.com> wrote:
On Wed, Apr 25, 2018 at 10:45 AM, Pedro Igor Silva
<psilva(a)redhat.com>
wrote:
> Adaptive authentication is a separated beast though as it may also be
> related to risk-based authentication/authorization. Some form of
calculation
> based on different sources of information to obtain some score to then
take
> some action. It is a hell of a feature depending on how much we want to
> invest in it.
>
Lol, that *WOULD* be cool......I always worried that step-up
authentication would be an edge case as most customers/users would
want to require 2nd factor authentication up front. Would a more
common case be that a certain client scope requires re-authentication?
i.e. to perform a sensitive operation? FYI, I'm completely
speculating here.
--
Bill Burke
Red Hat
12:05 p.m.
I think security levels should not be tied to client scopes directly because they
represent the client's view (what he needs to ask for). Security levels should be
bound to the resource servers view because he in the end decides what level of
authentication is necessary to get access, e.g. by means of having certain roles in the
token... However, I would like that feature.
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org]
On Behalf Of Bill Burke
Sent: Mittwoch, 25. April 2018 17:06
To: Pedro Igor Silva <psilva(a)redhat.com>
Cc: Thorgersen, Stian <stian(a)redhat.com>; keycloak-dev
<keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] OAuth2 Incremental Authorization
On Wed, Apr 25, 2018 at 10:45 AM, Pedro Igor Silva <psilva(a)redhat.com> wrote:
Adaptive authentication is a separated beast though as it may also be
related to risk-based authentication/authorization. Some form of
calculation based on different sources of information to obtain some
score to then take some action. It is a hell of a feature depending on
how much we want to invest in it.
Lol, that *WOULD* be cool......I always worried that step-up authentication would be an
edge case as most customers/users would want to require 2nd factor authentication up
front. Would a more common case be that a certain client scope requires
re-authentication?
i.e. to perform a sensitive operation? FYI, I'm completely speculating here.
--
Bill Burke
Red Hat
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
12:37 p.m.
On Wed, Apr 25, 2018 at 12:05 PM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com> wrote:
I think security levels should not be tied to client scopes directly
because they represent the client's view (what he needs to ask for). Security levels
should be bound to the resource servers view because he in the end decides what level of
authentication is necessary to get access, e.g. by means of having certain roles in the
token... However, I would like that feature.
So you think that security levels are decided by the app and not the
administrator? That an app would request a certain security level
rather than the adminstrator mandating it? IMO, I would think that it
would be better practice to have this metadata centralized and driven
by Keycloak rather than have the logic in the application. That way
all the complexity is centralized too and there's a lot less coding
the app/service needs to do. Think about it...if the app or service
decided on security levels, then any change in security policy would
require a refactor of the app/service and a respin/redeployment of it.
If everything is centralized then the app or service never needs to be
touched and can remain running. Security policy changes become
immediate.
--
Bill Burke
Red Hat
1:33 p.m.
I still think this should be handled centrally inside Keycloak. I would just tie it to
roles or any other token mapper generating a specific claim. Something in the line of the
client requests a token, Keycloak finds out that the claims to be added to the token
requires a certain security level, looks up the policy for that level and e.g. performs a
stronger authentication if required for that level.
Assigning roles/claims to security levels would have to be done by the service developer
since only he knows what these claims give access to. We would probably base this on
security classifications we have to define for all data we handle anyways.
However, you are right, the policies necessary to get access to certain classification
should be defined centrally and not only based on strength of authentication but might
depend on things like location, internal/external network and the like...
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
-----Original Message-----
From: Bill Burke [mailto:bburke@redhat.com]
Sent: Mittwoch, 25. April 2018 18:37
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>
Cc: Pedro Igor Silva <psilva(a)redhat.com>; Thorgersen, Stian
<stian(a)redhat.com>; keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] OAuth2 Incremental Authorization
On Wed, Apr 25, 2018 at 12:05 PM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com> wrote:
I think security levels should not be tied to client scopes directly
because they represent the client's view (what he needs to ask for). Security levels
should be bound to the resource servers view because he in the end decides what level of
authentication is necessary to get access, e.g. by means of having certain roles in the
token... However, I would like that feature.
So you think that security levels are decided by the app and not the administrator? That
an app would request a certain security level rather than the adminstrator mandating it?
IMO, I would think that it would be better practice to have this metadata centralized and
driven by Keycloak rather than have the logic in the application. That way all the
complexity is centralized too and there's a lot less coding the app/service needs to
do. Think about it...if the app or service decided on security levels, then any change in
security policy would require a refactor of the app/service and a respin/redeployment of
it.
If everything is centralized then the app or service never needs to be touched and can
remain running. Security policy changes become immediate.
--
Bill Burke
Red Hat
10:54 a.m.
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(a)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(a)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(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
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
Red Hat
10:13 a.m.
On Wed, Apr 25, 2018 at 10:31 AM, Pedro Igor Silva <psilva(a)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(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
>
2191
days inactive
2192
days old
13 comments
5 participants
participants (5)
-
Bill Burke -
Pedro Igor Silva -
Schuster Sebastian (INST/ESY1) -
Stian Thorgersen -
Youssef EL HOUTI