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>
> 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
>> 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
> On my phone so can't look at that. ID tokens have some expiration as
> access tokens surely?
It seems so
I did run some tests to make sure I'm not missing anything ... Hope I'm
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
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.
>> Pedro Igor
>> On Wed, Mar 27, 2019 at 9:43 PM Stian Thorgersen <sthorger(a)redhat.com>
>>> Based on feedback and also thinking about this a bit more I've now
>>> the proposal for Application Initiated Actions.
>>> Please read and comment on the update draft if you're interested.
>>> keycloak-dev mailing list