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@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@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):eyJqdGkiOiI4NWNlOGVlZS00N2Y5LTQzOTMtODc4Yi1iMjRiNTA0YWIzMWYiLCJleHAiOjE0NjI3NjY3MjMsIm5iZiI6MCwiaWF0IjoxNDYyNzY2NDIzLCJpc3MiOiJodHRwczovL2lkbS1zMi5zYi5kZXYuc2JldGVudi5jb20vYXV0aC9yZWFsbXMvZWxlY3RyaWNzaGVlcCIsImF1ZCI6ImVzIiwic3ViIjoiMDNlZGMzNzQtYzgyMC00ZDFhLWJhN2YtM2Y0NzlmOGRiMmM4IiwidHlwIjoiSUQiLCJhenAiOiJlcyIsInNlc3Npb25fc3RhdGUiOiIxY2I0Mjk3Zi04ODA3LTQ4ZWUtODBhNS1hMTI5NzRhN2EyYmQiLCJuYW1lIjoiZm5hbWUgbG5hbWUiLCJjdXN0SWQiOiIyNTY3NTgxIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW50aHRlc3QiLCJnaXZlbl9uYW1lIjoiZm5hbWUiLCJmYW1pbHlfbmFtZSI6ImxuYW1lIiwiZW1haWwiOiJub2JvZGF5QHNwb3J0c2JldC5jb20uYXUiLCJ0b2tlbiI6Ims4Z3NaKzlsV0dlZUVob212d09ocFk5bXlmeXdOQi9CWE1GWXBEQjErZTdHREJRa0h1R1BSYjJHOE4xYjFRdzJyUHdOVitvTTJzUUlMVVlXYXUvSHFFZ3JWUVhGeGdQd2dTVXl6UUtxaEYydW9KN3JzTFJkSFcza3ZRRy9JMUc1WlFtRnlnRE1va2NUIn0787 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/I1G5ZQmFygDMokcTWhich 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 MiloneDeveloperShine Consulting30/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--Fabricio MiloneDeveloperShine Consulting30/600 Bourke Street
Melbourne VIC 3000
T: 03 8488 9939
M: 04 3200 4006
www.shinetech.com a passion for excellence