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

[Stian Thorgersen]

On 30 May 2016 at 11:13, Marek Posolda <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.


>
>
> Marek
>
>
> On 27 May 2016 at 19:19, Marek Posolda <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/
>>
>> 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
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/f0c0b153/attachment-0001.html