12:09 a.m.
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(a)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(a)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","a...
>>
lname","custId":"2567581","preferred_username":"anthtest","given_name":"fname","family_name":"lname","email":"
>> noboday(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user