[keycloak-dev] Application Initiated Actions Draft #2

Pedro Igor Silva psilva at redhat.com
Mon Apr 1 15:43:32 EDT 2019


On Mon, Apr 1, 2019 at 3:44 PM Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On Mon, 1 Apr 2019, 18:54 Pedro Igor Silva, <psilva at 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/061693a8c981987216d37658c7937dd3ca613b50/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L741.
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 at 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/application-initiated-actions.md
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>


More information about the keycloak-dev mailing list