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

Stian Thorgersen sthorger at redhat.com
Tue May 10 00:37:17 EDT 2016


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


More information about the keycloak-user mailing list