<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">In OIDC specification, there is
mentioned that OIDC requests always need to contain "scope=openid"
in the initial Authorization request. If it doesn't contain it, it
is treated as the OAuth2 request, but not OIDC request. In future
releases, we plan to not include IDToken for such requests, which
don't contain "scope=openid" . See JIRA
<a class="moz-txt-link-freetext" href="https://issues.jboss.org/browse/KEYCLOAK-3237">https://issues.jboss.org/browse/KEYCLOAK-3237</a><br>
<br>
Isn't it sufficient to have just this possibility instead of
introduce another config switch?<br>
<br>
Marek<br>
<br>
On 25/07/16 19:10, Thomas Darimont wrote:<br>
</div>
<blockquote
cite="mid:CAK-7U1jio6SahQP=_w7adTwkO1oE6E5YvQTyw=_npx-rwXruTw@mail.gmail.com"
type="cite">
<div dir="ltr">Hello,
<div><br>
</div>
<div>I couldn't find the JIRA for the optional exclusion of the
IDToken when refreshing Access Tokens so I created:</div>
<div><a moz-do-not-send="true"
href="https://issues.jboss.org/browse/KEYCLOAK-3360">https://issues.jboss.org/browse/KEYCLOAK-3360</a><br>
</div>
<div><br>
</div>
<div>I also did a PR which implements that:</div>
<div><a moz-do-not-send="true"
href="https://github.com/keycloak/keycloak/pull/3069">https://github.com/keycloak/keycloak/pull/3069</a><br>
</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Thomas</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2016-05-31 8:59 GMT+02:00 Marek Posolda
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span>:<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 21:04, 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 12:03,
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 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"><a class="moz-txt-link-freetext" href="https://issues.jboss.org/browse/KEYCLOAK-3057">https://issues.jboss.org/browse/KEYCLOAK-3057</a></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>
</span> 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...<span class="HOEnZb"><font
color="#888888"><br>
<font color="#888888"><br>
Marek<br>
</font></font></span>
<div>
<div class="h5">
<blockquote 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><font
color="#888888"> Marek</font></span>
<div>
<div><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"><a class="moz-txt-link-abbreviated" href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a></a><br>
<a
moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-user"
rel="noreferrer"
target="_blank"><a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></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>
</div>
</div>
</div>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org">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>
</body>
</html>