<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 30/05/16 11:51, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAdr0iCF=4=93WnOK97HxFGUPCf5xtyFYLfHju4U4PBkoA@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.3.3"
target="_blank"><a class="moz-txt-link-freetext" href="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</a></a></span></div>
<div><span style="font-size:12.8px">[2] <a
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.12.2"
target="_blank"><a class="moz-txt-link-freetext" href="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</a></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>
</div>
</blockquote>
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.<br>
<br>
Marek<br>
<blockquote
cite="mid:CAJgngAdr0iCF=4=93WnOK97HxFGUPCf5xtyFYLfHju4U4PBkoA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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
moz-do-not-send="true"
href="mailto:mposolda@redhat.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:mposolda@redhat.com">mposolda@redhat.com</a></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 moz-do-not-send="true"
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 moz-do-not-send="true" href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true" href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org"
target="_blank">keycloak-user@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>