<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 30 May 2016 at 11:13, Marek Posolda <span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 30/05/16 08:02, Stian Thorgersen
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Create a JIRA for <span style="font-size:12.8px">ECDSA.
I don't think we could/should change the default, but could be
a configuration option for clients.</span></div>
</blockquote></span>
Added <a href="https://issues.jboss.org/browse/KEYCLOAK-3057" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-3057</a> with fix version
2.0.0.CR1 for now.<span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div><span style="font-size:12.8px"><br>
</span></div>
<div><span style="font-size:12.8px">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.</span></div>
<div><span style="font-size:12.8px"><br>
</span></div>
<div><span style="font-size:12.8px">[1] <a href="http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.3.3" target="_blank"></a><a href="http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.3.3" target="_blank">http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.3.3</a></span></div>
<div><span style="font-size:12.8px">[2] <a href="http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.12.2" target="_blank"></a><a href="http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.12.2" target="_blank">http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.12.2</a></span></div>
</div>
</blockquote></span>
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.<br>
<br>
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. <br>
<br>
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$<span style="background-color:#e4e4ff">AccessTokenResponseBuilder.</span>build()<span style="background-color:#e4e4ff"></span> 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).</div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="HOEnZb"><font color="#888888"><br>
<br>
Marek</font></span><div><div class="h5"><br>
<br>
<blockquote type="cite">
<div class="gmail_extra">
<div class="gmail_quote">On 27 May 2016 at 19:19, Marek Posolda
<span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>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?<br>
<br>
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).<br>
<br>
[1]
<a href="https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/" target="_blank">https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/</a><span><font color="#888888"><br>
<br>
Marek</font></span>
<div>
<div><br>
<br>
On 24/05/16 15:43, Bill Burke wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite"> 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.<br>
<br>
<div>On 5/24/16 5:46 AM, Matuszak, Eduard wrote:<br>
</div>
<blockquote type="cite"> <font face="Calibri" size="2"><span style="font-size:11pt">
<div>Hello </div>
<div> </div>
<div>Motivated by considerations on how to
improve the performance of the token
generation process I have two questions:</div>
<div> </div>
<ul style="margin:0;padding-left:36pt">
<li>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? </li>
</ul>
<div> </div>
<ul style="margin:0;padding-left:36pt">
<li>Is there a possibility to cause Keycloak
to generate more “simple” bearer tokens
then complex jwt-tokens?</li>
</ul>
<div> </div>
<div> </div>
<div><font face="Verdana" size="2"><span style="font-size:9pt">Best regards,
Eduard Matuszak</span></font></div>
<div> </div>
</span></font> <br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
keycloak-user mailing list
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre>
</blockquote>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
keycloak-user mailing list
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>