[keycloak-user] JWT - Base64 encode/decode issues

Tue May 10 01:53:33 EDT 2016

Tokens can be included in the URL if you use implicit flow (
https://tools.ietf.org/html/rfc6749#section-1.3.2) it's also mandated by
the JWT spec (
https://self-issued.info/docs/draft-ietf-oauth-json-web-token.html).

On 10 May 2016 at 07:48, Fabricio Milone <fabricio.milone at shinetech.com>
wrote:

> Well, that makes more sense now, since in Base64url padding is optional.
>
> Just wondering why you would use the URL safe when it is not included in a
> url...
>
> Thanks Stian.
>
> Regards.
>
> On 10 May 2016 at 15:21, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> The online checkers doesn't fix anything, they just use the correct
>> libraries. Plain base64 libraries doesn't work and that's expected because
>> it's not the correct algorithm. The tokens are base64url encoded to make
>> them URL safe so you need to use a base64url library. Alternatively, you
>> can convert it into a base64 padded string first, then use a base64 decoder.
>>
>> On 10 May 2016 at 07:09, Brian Cook <bcook at redhat.com> wrote:
>>
>>> I had the same problem as fabricio and implemented a version if the same
>>> solution.  The online checkers know how to fix the padding issue. Missing
>>> padding doesn't affect the payload contents of course, and it really
>>> depends on what language you are using when you decode. Python is strict
>>> about the padding and will throw an error if the input string isn't the
>>> right length.
>>>
>>> -Brian
>>> On May 9, 2016 10:38 PM, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>>>
>>>> It's base 64 url encoded, not base 64 encoded, so some padding is
>>>> removed. I've just checked the payload you have above that is missing using
>>>> http://kjur.github.io/jsjws/tool_b64udec.html and it's working just
>>>> fine.
>>>>
>>>> On 10 May 2016 at 01:49, Fabricio Milone <fabricio.milone at shinetech.com
>>>> > wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I've been experiencing some random issues when trying to decode the
>>>>> returned idToken from the /protocol/openid-connect/token call.
>>>>>
>>>>> I've found that sometimes the returned idToken is not multiple of 4
>>>>> and has no padding at the end of the payload section (where mappers are
>>>>> added). So the result is that I'm losing the last 2 characters of the last
>>>>> mapper value.
>>>>>
>>>>> This is one example of a failing token (payload only):
>>>>>
>>>>>
>>>>>> eyJqdGkiOiI4NWNlOGVlZS00N2Y5LTQzOTMtODc4Yi1iMjRiNTA0YWIzMWYiLCJleHAiOjE0NjI3NjY3MjMsIm5iZiI6MCwiaWF0IjoxNDYyNzY2NDIzLCJpc3MiOiJodHRwczovL2lkbS1zMi5zYi5kZXYuc2JldGVudi5jb20vYXV0aC9yZWFsbXMvZWxlY3RyaWNzaGVlcCIsImF1ZCI6ImVzIiwic3ViIjoiMDNlZGMzNzQtYzgyMC00ZDFhLWJhN2YtM2Y0NzlmOGRiMmM4IiwidHlwIjoiSUQiLCJhenAiOiJlcyIsInNlc3Npb25fc3RhdGUiOiIxY2I0Mjk3Zi04ODA3LTQ4ZWUtODBhNS1hMTI5NzRhN2EyYmQiLCJuYW1lIjoiZm5hbWUgbG5hbWUiLCJjdXN0SWQiOiIyNTY3NTgxIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW50aHRlc3QiLCJnaXZlbl9uYW1lIjoiZm5hbWUiLCJmYW1pbHlfbmFtZSI6ImxuYW1lIiwiZW1haWwiOiJub2JvZGF5QHNwb3J0c2JldC5jb20uYXUiLCJ0b2tlbiI6Ims4Z3NaKzlsV0dlZUVob212d09ocFk5bXlmeXdOQi9CWE1GWXBEQjErZTdHREJRa0h1R1BSYjJHOE4xYjFRdzJyUHdOVitvTTJzUUlMVVlXYXUvSHFFZ3JWUVhGeGdQd2dTVXl6UUtxaEYydW9KN3JzTFJkSFcza3ZRRy9JMUc1WlFtRnlnRE1va2NUIn0
>>>>>
>>>>>
>>>>> 787 chars (should be 788)
>>>>>
>>>>> if you try to decode it, you'll get:
>>>>>
>>>>>
>>>>>> {"jti":"85ce8eee-47f9-4393-878b-b24b504ab31f","exp":1462766723,"nbf":0,"iat":1462766423,"iss":"
>>>>>> https://idm-s2.sb.dev.sbetenv.com/auth/realms/electricsheep","aud":"es","sub":"03edc374-c820-4d1a-ba7f-3f479f8db2c8","typ":"ID","azp":"es","session_state":"1cb4297f-8807-48ee-80a5-a12974a7a2bd","name":"fname
>>>>>> lname","custId":"2567581","preferred_username":"anthtest","given_name":"fname","family_name":"lname","email":"
>>>>>> noboday at sportsbet.com.au
>>>>>> ","token":"k8gsZ+9lWGeeEhomvwOhpY9myfywNB/BXMFYpDB1+e7GDBQkHuGPRb2G8N1b1Qw2rPwNV+oM2sQILUYWau/HqEgrVQXFxgPwgSUyzQKqhF2uoJ7rsLRdHW3kvQG/I1G5ZQmFygDMokcT
>>>>>
>>>>>
>>>>> Which is incomplete. The last two chars (which are *"}*) are missing
>>>>> at the end.
>>>>>
>>>>> So now, if I take the correct complete json and try to encode using
>>>>> another library (as the one used here: https://www.base64encode.org/),
>>>>> I'll get:
>>>>>
>>>>>
>>>>>> eyJqdGkiOiI4NWNlOGVlZS00N2Y5LTQzOTMtODc4Yi1iMjRiNTA0YWIzMWYiLCJleHAiOjE0NjI3NjY3MjMsIm5iZiI6MCwiaWF0IjoxNDYyNzY2NDIzLCJpc3MiOiJodHRwczovL2lkbS1zMi5zYi5kZXYuc2JldGVudi5jb20vYXV0aC9yZWFsbXMvZWxlY3RyaWNzaGVlcCIsImF1ZCI6ImVzIiwic3ViIjoiMDNlZGMzNzQtYzgyMC00ZDFhLWJhN2YtM2Y0NzlmOGRiMmM4IiwidHlwIjoiSUQiLCJhenAiOiJlcyIsInNlc3Npb25fc3RhdGUiOiIxY2I0Mjk3Zi04ODA3LTQ4ZWUtODBhNS1hMTI5NzRhN2EyYmQiLCJuYW1lIjoiZm5hbWUgbG5hbWUiLCJjdXN0SWQiOiIyNTY3NTgxIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW50aHRlc3QiLCJnaXZlbl9uYW1lIjoiZm5hbWUiLCJmYW1pbHlfbmFtZSI6ImxuYW1lIiwiZW1haWwiOiJub2JvZGF5QHNwb3J0c2JldC5jb20uYXUiLCJ0b2tlbiI6Ims4Z3NaKzlsV0dlZUVob212d09ocFk5bXlmeXdOQi9CWE1GWXBEQjErZTdHREJRa0h1R1BSYjJHOE4xYjFRdzJyUHdOVitvTTJzUUlMVVlXYXUvSHFFZ3JWUVhGeGdQd2dTVXl6UUtxaEYydW9KN3JzTFJkSFcza3ZRRy9JMUc1WlFtRnlnRE1va2NUIn0
>>>>>> *=*
>>>>>
>>>>>
>>>>> (788 chars, which is ok)
>>>>>
>>>>> Note the equal sign at the end.
>>>>>
>>>>> I'm wondering why Keycloak is not adding those paddings, is that a bug
>>>>> on the lib you are using to encode the payload?
>>>>>
>>>>> As for now, I'm using a workaround that checks for the length of the
>>>>> token and adds the missing padding when needed before try to decode it.
>>>>>
>>>>> while (payload.length() % 4 != 0) payload += "=";
>>>>>
>>>>>
>>>>> That works but it is not ideal.
>>>>>
>>>>> *Should I create a bug on Keycloak's issue tracker?*
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> Regards,
>>>>> Fab
>>>>> --
>>>>> *Fabricio Milone*
>>>>> Developer
>>>>>
>>>>> *Shine Consulting *
>>>>>
>>>>> 30/600 Bourke Street
>>>>>
>>>>> Melbourne VIC 3000
>>>>>
>>>>> T: 03 8488 9939
>>>>>
>>>>> M: 04 3200 4006
>>>>>
>>>>>
>>>>> www.shinetech.com  *a* passion for excellence
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> 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
>>>>
>>>
>>
>
>
> --
> *Fabricio Milone*
> Developer
>
> *Shine Consulting *
>
> 30/600 Bourke Street
>
> Melbourne VIC 3000
>
> T: 03 8488 9939
>
> M: 04 3200 4006
>
>
> www.shinetech.com  *a* passion for excellence
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/e2f1fc18/attachment-0001.html 