[keycloak-user] Token generation: possibilities to improve performance

Mon Jul 25 13:10:59 EDT 2016

Hello,

I couldn't find the JIRA for the optional exclusion of the IDToken when
refreshing Access Tokens so I created:
https://issues.jboss.org/browse/KEYCLOAK-3360

I also did a PR which implements that:
https://github.com/keycloak/keycloak/pull/3069

Cheers,
Thomas

2016-05-31 8:59 GMT+02:00 Marek Posolda <mposolda at redhat.com>:

> On 30/05/16 21:04, Stian Thorgersen wrote:
>
>
>
> On 30 May 2016 at 12:03, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 30/05/16 11:51, Stian Thorgersen wrote:
>>
>>
>>
>> On 30 May 2016 at 11:13, Marek Posolda < <mposolda at redhat.com>
>> mposolda at redhat.com> wrote:
>>
>>> On 30/05/16 08:02, Stian Thorgersen wrote:
>>>
>>> Create a JIRA for ECDSA. I don't think we could/should change the
>>> default, but could be a configuration option for clients.
>>>
>>> Added https://issues.jboss.org/browse/KEYCLOAK-3057 with fix version
>>> 2.0.0.CR1 for now.
>>>
>>>
>>> Looking at OpenID Connect spec it looks like ID token should always be
>>> generated in token response [1]. However, it should not be generated in
>>> refresh [2] response.
>>>
>>> [1]
>>> <http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.3.3>
>>> http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.3.3
>>> [2]
>>> <http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.12.2>
>>> http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.12.2
>>>
>>> hmm... I am reading 12.2 that refresh response "might not" contain ID
>>> Token, hence it's nothing bad if it contains it. So looks we are currently
>>> specs compliant if we have IDToken in both code-to-token response and
>>> refresh response.
>>>
>>> What I mean is, that flag for skip IDToken generation might be just
>>> optional and disabled by default. So by default, IDToken is available and
>>> all the communication is OIDC compliant. However if someone doesn't need
>>> IDToken and wants to save some performance, he may skip the IDToken
>>> generation.
>>>
>>> A week before, I've tried some JProfiler testing of login-logout test
>>> and token generation was the main CPU consumption (I still had just 1
>>> hashIteration during this profiling, with 20000 it will be likely very
>>> different though). I saw 40% of CPU time in TokenManager$
>>> AccessTokenResponseBuilder.build() due there are 3 tokens signature
>>> here. The option to reduce it from 3 to 2 might slightly improve some CPU
>>> cycles "for free" (security won't be reduced).
>>>
>>
>> I'd argue that we should just include ID token from the authorization
>> response, while never in the refresh response. That results in better
>> performance without the need for a config option.
>>
>> Won't that break compatibility for some client applications, which
>> actually use IDToken and rely on the fact that it's properly refreshed
>> every time? Among other things, IDToken contains fields like "exp" , which
>> might then contain  expired value as it won't be updated during refreshes.
>> Not sure if users won't be confused due to this.
>>
>
> Surely the exp for an IDToken should be set to the session expiration and
> not to the expiration of access token though? Do we even update the profile
> details in the token or just fill it with whatever was there before?
>
> That's not what we are doing now. Right now, all IDToken claims (including
> expiration) are copied from accessToken. So IDToken expiration is by
> default defacto just 5 minutes or so. And all the claims are always updated
> during refresh. So if we don't refresh IDToken we lost this and IDToken
> will always contain claims from the time of login. Not sure if it's too bad
> or not, however some client apps, which use IDToken (like our demo for
> example) might be confused that IDToken will still contain old values after
> refresh...
>
> Marek
>
> Marek
>>
>>
>>
>>>
>>>
>>> Marek
>>>
>>>
>>> On 27 May 2016 at 19:19, Marek Posolda < <mposolda at redhat.com>
>>> mposolda at redhat.com> wrote:
>>>
>>>> Regarding this, I wonder if we should add support for ECDSA based
>>>> signatures as an alternative to RSA? Just went through some interesting
>>>> blog [1] , which mentions that 256-bits ECDSA has around 9.5 times better
>>>> performance of signature generation than 2048-bits RSA. The time of
>>>> signature verification seems to be slightly worse for ECDSA (see second
>>>> comment), however there is also increased security (256-ECDSA is
>>>> equivalient of 3248 RSA according to blog). Maybe it's something we can
>>>> look at?
>>>>
>>>> Also the optional flag to skip IDToken generation will be good too IMO.
>>>> AFAIK the point of IDToken is the compliance with OIDC specification.
>>>> However in case of Keycloak accessToken usually contains all the info like
>>>> IDToken (+ some more) and it's the accessToken, which is used in REST
>>>> endpoints. So with regards to that, most of the Keycloak-secured
>>>> applications can live just with access+refresh token and don't need ID
>>>> Token at all. So if just 2 tokens needs to be signed instead of 3, we have
>>>> performance gain "for free" (no decrease of security, just one less useless
>>>> token).
>>>>
>>>> [1]
>>>> <https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/>
>>>> https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/
>>>>
>>>> Marek
>>>>
>>>>
>>>> On 24/05/16 15:43, Bill Burke wrote:
>>>>
>>>> Are you sure the performance gains are worth less security?  What kind
>>>> of performance are you actually worried about?  Network (size of tokens) or
>>>> CPU (signatures/marshaling/unmarshalling)?  If anything, these signatures
>>>> are only going to get stronger in future releases.
>>>>
>>>> On 5/24/16 5:46 AM, Matuszak, Eduard wrote:
>>>>
>>>> Hello
>>>>
>>>> Motivated by considerations on how to improve the performance of the
>>>> token generation process I have two questions:
>>>>
>>>>
>>>>    - I noticed that Keycloak’s token generation via endpoint
>>>>    “auth/realms/ccp/protocol/openid-connect/token” generates a triple of
>>>>    tokens (access-, refresh- and id-token). Is there any possibility to
>>>>    dispense with the id-token generation?
>>>>
>>>>
>>>>
>>>>    - Is there a possibility to cause Keycloak to generate more
>>>>    “simple” bearer tokens then complex jwt-tokens?
>>>>
>>>>
>>>>
>>>> Best regards, Eduard Matuszak
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>>
>>
>>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160725/92da72d5/attachment-0001.html