<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 21:04, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAcxJcB1tbL+w8ZUQK6R0U-xxd2NfB7qsxv3gd==hJChvg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 30 May 2016 at 12:03, 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 11:51, Stian Thorgersen wrote:<br>
</div>
<blockquote 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"><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"><span>
<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><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>
</span> 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.</div>
</blockquote>
<div><br>
</div>
<div>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?</div>
</div>
</div>
</div>
</blockquote>
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...<br>
<font color="#888888"><br>
Marek<br>
</font>
<blockquote
cite="mid:CAJgngAcxJcB1tbL+w8ZUQK6R0U-xxd2NfB7qsxv3gd==hJChvg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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"> Marek</font></span>
<div>
<div class="h5"><br>
<blockquote 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><font
color="#888888"><br>
<br>
Marek</font></span>
<div>
<div><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"><a class="moz-txt-link-freetext" href="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/</a></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>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>