[keycloak-dev] Application Initiated Actions Draft #2

[Pedro Igor Silva]

On Tue, Apr 2, 2019 at 3:47 AM Stian Thorgersen <sthorger at redhat.com> 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?
>

I'm not sure. As you said already, ID Tokens is all about authentication
while the AT is about authorization. Given their natures, I think they
should not have the same expiration? Or we should at least make this
configurable so people can define ID Token life time accordingly with their
requirements.

ID Token lifetime should be enough to authenticate the user to a client.
Which can differ from the lifetime of AT/authorization.


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

I agree, AT and RT leakage is much worse. But for ID Tokens the concern
should be how these services are accepting bearer tokens and all the
constraints they are imposing to accept them. For instance, audience
checks, etc.


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