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