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

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&gt; 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&gt; > 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 >

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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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 >>> >> > -- *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