[keycloak-user] Token generation: possibilities to improve performance

Thu Aug 4 06:25:05 EDT 2016

You're right, it is better to follow the spec than to introduce a
workaround via the switch.
So I'm fine with closing the PR.

Cheers,
Thomas

2016-08-04 12:17 GMT+02:00 Marek Posolda <mposolda at redhat.com>:

> 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
> https://issues.jboss.org/browse/KEYCLOAK-3237
>
> Isn't it sufficient to have just this possibility instead of introduce
> another config switch?
>
> Marek
>
>
> On 25/07/16 19:10, Thomas Darimont wrote:
>
> 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 at redhat.com>:
>
>> On 30/05/16 21:04, Stian Thorgersen wrote:
>>
>>
>>
>> On 30 May 2016 at 12:03, Marek Posolda < <mposolda at redhat.com>
>> mposolda at redhat.com> wrote:
>>
>>> On 30/05/16 11:51, Stian Thorgersen wrote:
>>>
>>>
>>>
>>> On 30 May 2016 at 11:13, Marek Posolda < <mposolda at redhat.com>
>>> mposolda at 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>
>>>> 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>
>>>> 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>
>>>> 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 at redhat.com>
>>>> mposolda at 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-better-internet/>
>>>>> https://blog.cloudflare.com/ecdsa-the-digital-signature-
>>>>> algorithm-of-a-better-internet/
>>>>>
>>>>> 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 at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> <keycloak-user at lists.jboss.org>keycloak-user at lists.jboss.org
>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160804/f2eabbb7/attachment-0001.html 