[keycloak-dev] Application Initiated Actions Draft #2

[Marek Posolda]

On 02/04/2019 08:47, Stian Thorgersen wrote:
> 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?
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 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
>>>>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev