[keycloak-dev] Application Initiated Actions Draft #2

[Stian Thorgersen]

On Mon, 1 Apr 2019 at 21:43, Pedro Igor Silva <psilva at redhat.com> wrote:

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

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