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

Tue May 10 01:48:34 EDT 2016

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/1ed28b52/attachment.html 