7:36 p.m.
Based on feedback and also thinking about this a bit more I've now updated
the proposal for Application Initiated Actions.
Please read and comment on the update draft if you're interested.
https://github.com/keycloak/keycloak-community/blob/master/design/applica...
2:59 a.m.
+1 for the proposal.
Thanks,
Marek
On 28/03/2019 01:36, Stian Thorgersen wrote:
Based on feedback and also thinking about this a bit more I've
now updated
the proposal for Application Initiated Actions.
Please read and comment on the update draft if you're interested.
https://github.com/keycloak/keycloak-community/blob/master/design/applica...
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:26 a.m.
I like the proposal,
Thanks,
V.
On 3/28/19 8:59 AM, Marek Posolda wrote:
+1 for the proposal.
Thanks,
Marek
On 28/03/2019 01:36, Stian Thorgersen wrote:
> Based on feedback and also thinking about this a bit more I've now updated
> the proposal for Application Initiated Actions.
>
> Please read and comment on the update draft if you're interested.
>
>
https://github.com/keycloak/keycloak-community/blob/master/design/applica...
> _______________________________________________
> 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
7:43 a.m.
+1 from me as well.
Thinking in terms of Account Console, I'm starting to wonder if AIA's
mean we need to take a fresh look from a UXD perspective. Almost half of
the functionality will be taken over by AIA. So that means a lot of
what is currently in the navigation menu results in a new screen that
replaces the console. It's no longer "click a link and get something
new in the content area".
If everything was implemented as AIA then the Account Console would
become more of an application launcher. But sounds like we will end up
with a hybrid or some sort.
Stan
On 3/27/2019 8:36 PM, Stian Thorgersen wrote:
Based on feedback and also thinking about this a bit more I've
now updated
the proposal for Application Initiated Actions.
Please read and comment on the update draft if you're interested.
https://github.com/keycloak/keycloak-community/blob/master/design/applica...
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:56 p.m.
Great stuff, I really liked the second version.
+1
On 2019-03-28, Stian Thorgersen wrote:
Based on feedback and also thinking about this a bit more I've
now updated
the proposal for Application Initiated Actions.
Please read and comment on the update draft if you're interested.
https://github.com/keycloak/keycloak-community/blob/master/design/applica...
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
abstractj
11:54 a.m.
Hi Stian,
A few additional comments:
* "or alternatively the application can include an id_token_hint with the
request that proves the application does not need consent from the user"
I understand that ID Tokens should be short-lived, but aren't we setting
the exp of ID tokens with the value from access tokens? See
org.keycloak.protocol.oidc.TokenManager.AccessTokenResponseBuilder#generateIDToken.
In addition to that, I don't think that using a front-channel to pass
tokens is something we want to do given that there are a lot of
considerations around this approach. If we are really going this way, I
think we should at least consider some form of proof-of-possession.
For last, maybe you should explicitly mention the usage of TLS?
Regards.
Pedro Igor
On Wed, Mar 27, 2019 at 9:43 PM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
Based on feedback and also thinking about this a bit more I've
now updated
the proposal for Application Initiated Actions.
Please read and comment on the update draft if you're interested.
https://github.com/keycloak/keycloak-community/blob/master/design/applica...
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:44 p.m.
On Mon, 1 Apr 2019, 18:54 Pedro Igor Silva, <psilva(a)redhat.com> wrote:
Hi Stian,
A few additional comments:
* "or alternatively the application can include an id_token_hint with the
request that proves the application does not need consent from the user"
I understand that ID Tokens should be short-lived, but aren't we setting
the exp of ID tokens with the value from access tokens? See
org.keycloak.protocol.oidc.TokenManager.AccessTokenResponseBuilder#generateIDToken.
On my phone so can't look at that. ID tokens have some expiration as access
tokens surely?
In addition to that, I don't think that using a front-channel to
pass
tokens is something we want to do given that there are a lot of
considerations around this approach. If we are really going this way, I
think we should at least consider some form of proof-of-possession.
I'm not 100% convinced about id_token_hint either, but OIDC spec already
uses id_token_hint several places. It's in the auth endpoint already (not
something we're adding) also used in logout specs. I also struggle to see
how it can be missused even if obtained.
Proof of possession is a nice idea, but not sure how that could be done
without storing additional things at the server side.
For last, maybe you should explicitly mention the usage of TLS?
I do believe that is already implied? Oauth/OIDC/tokens are completely
insecure without TLS.
Regards.
Pedro Igor
On Wed, Mar 27, 2019 at 9:43 PM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> Based on feedback and also thinking about this a bit more I've now updated
> the proposal for Application Initiated Actions.
>
> Please read and comment on the update draft if you're interested.
>
>
>
https://github.com/keycloak/keycloak-community/blob/master/design/applica...
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
2:43 p.m.
On Mon, Apr 1, 2019 at 3:44 PM Stian Thorgersen <sthorger(a)redhat.com> wrote:
On Mon, 1 Apr 2019, 18:54 Pedro Igor Silva, <psilva(a)redhat.com> wrote:
> Hi Stian,
>
> A few additional comments:
>
> * "or alternatively the application can include an id_token_hint with the
> request that proves the application does not need consent from the user"
>
> I understand that ID Tokens should be short-lived, but aren't we setting
> the exp of ID tokens with the value from access tokens? See
> org.keycloak.protocol.oidc.TokenManager.AccessTokenResponseBuilder#generateIDToken.
>
On my phone so can't look at that. ID tokens have some expiration as
access tokens surely?
It seems so
https://github.com/keycloak/keycloak/blob/061693a8c981987216d37658c7937dd....
I did run some tests to make sure I'm not missing anything ... Hope I'm
wrong :)
> In addition to that, I don't think that using a front-channel to pass
> tokens is something we want to do given that there are a lot of
> considerations around this approach. If we are really going this way, I
> think we should at least consider some form of proof-of-possession.
>
I'm not 100% convinced about id_token_hint either, but OIDC spec already
uses id_token_hint several places. It's in the auth endpoint already (not
something we're adding) also used in logout specs. I also struggle to see
how it can be missused even if obtained.
Proof of possession is a nice idea, but not sure how that could be done
without storing additional things at the server side.
I can look at that if you want and see if we can apply here some PoP
technique.
I missed this parameter in OIDC spec. So maybe we are cool then and should
just use it? Kind of interesting this, you see a lot of warnings in OAuth
2.0 about using front-channel to deliver tokens (e.g.: implicit) and in
OIDC I did not find anything ... Well, we are backed by the spec then to
keep this simple...
Of course, this is different than sending tokens to a client which you
don't control. But still, suffer some of the same vulnerabilities ...
> For last, maybe you should explicitly mention the usage of TLS?
>
I do believe that is already implied? Oauth/OIDC/tokens are completely
insecure without TLS.
Yeah, I just wanted to highlight this based on the list of considerations
you added into "Notes on id_token hint". You pointed out some that could be
considered to be an implied concern.
> Regards.
> Pedro Igor
>
> On Wed, Mar 27, 2019 at 9:43 PM Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>
>> Based on feedback and also thinking about this a bit more I've now
>> updated
>> the proposal for Application Initiated Actions.
>>
>> Please read and comment on the update draft if you're interested.
>>
>>
>>
https://github.com/keycloak/keycloak-community/blob/master/design/applica...
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
1:47 a.m.
On Mon, 1 Apr 2019 at 21:43, Pedro Igor Silva <psilva(a)redhat.com> wrote:
On Mon, Apr 1, 2019 at 3:44 PM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
>
>
> On Mon, 1 Apr 2019, 18:54 Pedro Igor Silva, <psilva(a)redhat.com> wrote:
>
>> Hi Stian,
>>
>> A few additional comments:
>>
>> * "or alternatively the application can include an id_token_hint with
>> the request that proves the application does not need consent from the
user"
>>
>> I understand that ID Tokens should be short-lived, but aren't we setting
>> the exp of ID tokens with the value from access tokens? See
>>
org.keycloak.protocol.oidc.TokenManager.AccessTokenResponseBuilder#generateIDToken.
>>
>
> On my phone so can't look at that. ID tokens have some expiration as
> access tokens surely?
>
It seems so
https://github.com/keycloak/keycloak/blob/061693a8c981987216d37658c7937dd....
I did run some tests to make sure I'm not missing anything ... Hope I'm
wrong :)
They should have the same expiration surely?
>
>
>> In addition to that, I don't think that using a front-channel to pass
>> tokens is something we want to do given that there are a lot of
>> considerations around this approach. If we are really going this way, I
>> think we should at least consider some form of proof-of-possession.
>>
>
> I'm not 100% convinced about id_token_hint either, but OIDC spec already
> uses id_token_hint several places. It's in the auth endpoint already (not
> something we're adding) also used in logout specs. I also struggle to see
> how it can be missused even if obtained.
>
> Proof of possession is a nice idea, but not sure how that could be done
> without storing additional things at the server side.
>
I can look at that if you want and see if we can apply here some PoP
technique.
Sure - we could potentially support both id_token_hint and a PoP technique
(if we can do the latter in a nice way)
I missed this parameter in OIDC spec. So maybe we are cool then and should
just use it? Kind of interesting this, you see a lot of warnings in OAuth
2.0 about using front-channel to deliver tokens (e.g.: implicit) and in
OIDC I did not find anything ... Well, we are backed by the spec then to
keep this simple...
There's a difference in leaking a refresh token and access token to leaking
a ID token IMO. From thinking about it I can't see how you would use a
leaked ID token as apps don't accept them in the same way as services
accept access tokens.
Of course, this is different than sending tokens to a client which you
don't control. But still, suffer some of the same vulnerabilities ...
>
>
>> For last, maybe you should explicitly mention the usage of TLS?
>>
>
> I do believe that is already implied? Oauth/OIDC/tokens are completely
> insecure without TLS.
>
Yeah, I just wanted to highlight this based on the list of considerations
you added into "Notes on id_token hint". You pointed out some that could be
considered to be an implied concern.
>
>
>> Regards.
>> Pedro Igor
>>
>> On Wed, Mar 27, 2019 at 9:43 PM Stian Thorgersen <sthorger(a)redhat.com>
>> wrote:
>>
>>> Based on feedback and also thinking about this a bit more I've now
>>> updated
>>> the proposal for Application Initiated Actions.
>>>
>>> Please read and comment on the update draft if you're interested.
>>>
>>>
>>>
https://github.com/keycloak/keycloak-community/blob/master/design/applica...
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
8:12 a.m.
On 02/04/2019 08:47, Stian Thorgersen wrote:
On Mon, 1 Apr 2019 at 21:43, Pedro Igor Silva
<psilva(a)redhat.com> wrote:
>
> On Mon, Apr 1, 2019 at 3:44 PM Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>
>>
>> On Mon, 1 Apr 2019, 18:54 Pedro Igor Silva, <psilva(a)redhat.com> wrote:
>>
>>> Hi Stian,
>>>
>>> A few additional comments:
>>>
>>> * "or alternatively the application can include an id_token_hint with
>>> the request that proves the application does not need consent from the
user"
>>>
>>> I understand that ID Tokens should be short-lived, but aren't we setting
>>> the exp of ID tokens with the value from access tokens? See
>>>
org.keycloak.protocol.oidc.TokenManager.AccessTokenResponseBuilder#generateIDToken.
>>>
>> On my phone so can't look at that. ID tokens have some expiration as
>> access tokens surely?
>>
> It seems so
>
https://github.com/keycloak/keycloak/blob/061693a8c981987216d37658c7937dd....
> I did run some tests to make sure I'm not missing anything ... Hope I'm
> wrong :)
>
They should have the same expiration surely?
Yes, they have same expiration.
>
>>
>>> In addition to that, I don't think that using a front-channel to pass
>>> tokens is something we want to do given that there are a lot of
>>> considerations around this approach. If we are really going this way, I
>>> think we should at least consider some form of proof-of-possession.
>>>
>> I'm not 100% convinced about id_token_hint either, but OIDC spec already
>> uses id_token_hint several places. It's in the auth endpoint already (not
>> something we're adding) also used in logout specs. I also struggle to see
>> how it can be missused even if obtained.
>>
>> Proof of possession is a nice idea, but not sure how that could be done
>> without storing additional things at the server side.
>>
> I can look at that if you want and see if we can apply here some PoP
> technique.
>
Sure - we could potentially support both id_token_hint and a PoP technique
(if we can do the latter in a nice way)
> I missed this parameter in OIDC spec. So maybe we are cool then and should
> just use it? Kind of interesting this, you see a lot of warnings in OAuth
> 2.0 about using front-channel to deliver tokens (e.g.: implicit) and in
> OIDC I did not find anything ... Well, we are backed by the spec then to
> keep this simple...
>
There's a difference in leaking a refresh token and access token to leaking
a ID token IMO. From thinking about it I can't see how you would use a
leaked ID token as apps don't accept them in the same way as services
accept access tokens.
Hopefully yes, but even if ID Token is leaked, it is not ideal. In the
past, we had issues with the fact that IDToken could be used as
accessToken. This shouldn't be an issue in our adapters, where we test
the "typ" and audience in the tokens. But some 3rd party service can be
buggy and still accept ID Token as access token due some missing checks.
Hopefully this is not big issue in reality...
Marek
> Of course, this is different than sending tokens to a client which you
> don't control. But still, suffer some of the same vulnerabilities ...
>
>
>>
>>> For last, maybe you should explicitly mention the usage of TLS?
>>>
>> I do believe that is already implied? Oauth/OIDC/tokens are completely
>> insecure without TLS.
>>
> Yeah, I just wanted to highlight this based on the list of considerations
> you added into "Notes on id_token hint". You pointed out some that could
be
> considered to be an implied concern.
>
>
>>
>>> Regards.
>>> Pedro Igor
>>>
>>> On Wed, Mar 27, 2019 at 9:43 PM Stian Thorgersen <sthorger(a)redhat.com>
>>> wrote:
>>>
>>>> Based on feedback and also thinking about this a bit more I've now
>>>> updated
>>>> the proposal for Application Initiated Actions.
>>>>
>>>> Please read and comment on the update draft if you're interested.
>>>>
>>>>
>>>>
https://github.com/keycloak/keycloak-community/blob/master/design/applica...
>>>> _______________________________________________
>>>> 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
8:24 a.m.
On Tue, Apr 2, 2019 at 10:12 AM Marek Posolda <mposolda(a)redhat.com> wrote:
> There's a difference in leaking a refresh token and access
token to
leaking
> a ID token IMO. From thinking about it I can't see how you would use a
> leaked ID token as apps don't accept them in the same way as services
> accept access tokens.
Hopefully yes, but even if ID Token is leaked, it is not ideal. In the
past, we had issues with the fact that IDToken could be used as
accessToken. This shouldn't be an issue in our adapters, where we test
the "typ" and audience in the tokens. But some 3rd party service can be
buggy and still accept ID Token as access token due some missing checks.
Hopefully this is not big issue in reality...
+1. But audience check is still false by default, right?
8:39 a.m.
On 02/04/2019 15:24, Pedro Igor Silva wrote:
On Tue, Apr 2, 2019 at 10:12 AM Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
> There's a difference in leaking a refresh token and access token
to leaking
> a ID token IMO. From thinking about it I can't see how you would
use a
> leaked ID token as apps don't accept them in the same way as
services
> accept access tokens.
Hopefully yes, but even if ID Token is leaked, it is not ideal. In
the
past, we had issues with the fact that IDToken could be used as
accessToken. This shouldn't be an issue in our adapters, where we
test
the "typ" and audience in the tokens. But some 3rd party service
can be
buggy and still accept ID Token as access token due some missing
checks.
Hopefully this is not big issue in reality...
+1. But audience check is still false by default, right?
Yes. But the "typ" is checked in our adapters, so you won't be able to
use ID token as access token. I think the issue could be just for 3rd
party adapters, which may not check all the necessary things.
Marek
8:19 a.m.
On Tue, Apr 2, 2019 at 3:47 AM Stian Thorgersen <sthorger(a)redhat.com> wrote:
On Mon, 1 Apr 2019 at 21:43, Pedro Igor Silva <psilva(a)redhat.com> wrote:
>
>
> On Mon, Apr 1, 2019 at 3:44 PM Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>
>>
>>
>> On Mon, 1 Apr 2019, 18:54 Pedro Igor Silva, <psilva(a)redhat.com> wrote:
>>
>>> Hi Stian,
>>>
>>> A few additional comments:
>>>
>>> * "or alternatively the application can include an id_token_hint with
>>> the request that proves the application does not need consent from the
user"
>>>
>>> I understand that ID Tokens should be short-lived, but aren't we
>>> setting the exp of ID tokens with the value from access tokens? See
>>>
org.keycloak.protocol.oidc.TokenManager.AccessTokenResponseBuilder#generateIDToken.
>>>
>>
>> On my phone so can't look at that. ID tokens have some expiration as
>> access tokens surely?
>>
>
> It seems so
>
https://github.com/keycloak/keycloak/blob/061693a8c981987216d37658c7937dd....
> I did run some tests to make sure I'm not missing anything ... Hope I'm
> wrong :)
>
They should have the same expiration surely?
I'm not sure. As you said already, ID Tokens is all about authentication
while the AT is about authorization. Given their natures, I think they
should not have the same expiration? Or we should at least make this
configurable so people can define ID Token life time accordingly with their
requirements.
ID Token lifetime should be enough to authenticate the user to a client.
Which can differ from the lifetime of AT/authorization.
>
>
>>
>>
>>> In addition to that, I don't think that using a front-channel to pass
>>> tokens is something we want to do given that there are a lot of
>>> considerations around this approach. If we are really going this way, I
>>> think we should at least consider some form of proof-of-possession.
>>>
>>
>> I'm not 100% convinced about id_token_hint either, but OIDC spec already
>> uses id_token_hint several places. It's in the auth endpoint already (not
>> something we're adding) also used in logout specs. I also struggle to see
>> how it can be missused even if obtained.
>>
>> Proof of possession is a nice idea, but not sure how that could be done
>> without storing additional things at the server side.
>>
>
> I can look at that if you want and see if we can apply here some PoP
> technique.
>
Sure - we could potentially support both id_token_hint and a PoP technique
(if we can do the latter in a nice way)
>
> I missed this parameter in OIDC spec. So maybe we are cool then and
> should just use it? Kind of interesting this, you see a lot of warnings in
> OAuth 2.0 about using front-channel to deliver tokens (e.g.: implicit) and
> in OIDC I did not find anything ... Well, we are backed by the spec then to
> keep this simple...
>
There's a difference in leaking a refresh token and access token to
leaking a ID token IMO. From thinking about it I can't see how you would
use a leaked ID token as apps don't accept them in the same way as services
accept access tokens.
I agree, AT and RT leakage is much worse. But for ID Tokens the concern
should be how these services are accepting bearer tokens and all the
constraints they are imposing to accept them. For instance, audience
checks, etc.
>
> Of course, this is different than sending tokens to a client which you
> don't control. But still, suffer some of the same vulnerabilities ...
>
>
>>
>>
>>> For last, maybe you should explicitly mention the usage of TLS?
>>>
>>
>> I do believe that is already implied? Oauth/OIDC/tokens are completely
>> insecure without TLS.
>>
>
> Yeah, I just wanted to highlight this based on the list of considerations
> you added into "Notes on id_token hint". You pointed out some that could
be
> considered to be an implied concern.
>
>
>>
>>
>>> Regards.
>>> Pedro Igor
>>>
>>> On Wed, Mar 27, 2019 at 9:43 PM Stian Thorgersen <sthorger(a)redhat.com>
>>> wrote:
>>>
>>>> Based on feedback and also thinking about this a bit more I've now
>>>> updated
>>>> the proposal for Application Initiated Actions.
>>>>
>>>> Please read and comment on the update draft if you're interested.
>>>>
>>>>
>>>>
https://github.com/keycloak/keycloak-community/blob/master/design/applica...
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
2095
days inactive
2100
days old
12 comments
6 participants
participants (6)
-
Bruno Oliveira -
Marek Posolda -
Pedro Igor Silva -
Stan Silvert -
Stian Thorgersen -
Vlasta Ramik