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@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@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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user

_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user