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 https://lists.jboss.org/mailman/listinfo/keycloak-user

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 listkeycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing listkeycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Create a JIRA for ECDSA. I don't think we could/should change the default, but could be a configuration option for clients.

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

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

On 30 May 2016 at 11:13, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: 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). 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.

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 > >

On 30 May 2016 at 12:03, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: On 30/05/16 11:51, Stian Thorgersen wrote: > > > On 30 May 2016 at 11:13, Marek Posolda <mposolda(a)redhat.com > <mailto:mposolda@redhat.com>> wrote: > > 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). > > > 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. 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. 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?

Marek > > > 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 >> >> > >

Hello, I couldn't find the JIRA for the optional exclusion of the IDToken when refreshing Access Tokens so I created: https://issues.jboss.org/browse/KEYCLOAK-3360 I also did a PR which implements that: https://github.com/keycloak/keycloak/pull/3069 Cheers, Thomas 2016-05-31 8:59 GMT+02:00 Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>>: On 30/05/16 21:04, Stian Thorgersen wrote: > > > On 30 May 2016 at 12:03, Marek Posolda <mposolda(a)redhat.com > <mailto:mposolda@redhat.com>> wrote: > > On 30/05/16 11:51, Stian Thorgersen wrote: >> >> >> On 30 May 2016 at 11:13, Marek Posolda <mposolda(a)redhat.com >> <mailto:mposolda@redhat.com>> wrote: >> >> 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). >> >> >> 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. > 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. > > > 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? 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... Marek > > Marek > >> >> >> 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 >>> >>> >> >> > > _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user