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

[Stian Thorgersen]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/10c0e43a/attachment-0001.html