4:13 a.m.
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
[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).
Marek
On 27 May 2016 at 19:19, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@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-be...
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 list
>> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user