On 28 May 2018 at 09:19, Adis Nezirovic <[email protected]> wrote: > On 05/26/2018 04:27 PM, Jonathan Matthews wrote: >> Hello folks, >> >> The payload (and other parts) of a JSON Web Token (JWT, a popular and >> growing auth standard: https://tools.ietf.org/html/rfc7519) is base64 >> encoded. >> >> Unfortunately, the payload encoding (specified in >> https://tools.ietf.org/html/rfc7515) is defined as the "URL safe" >> variant. This variant allows for the lossless omission of base64 >> padding ("=" or "=="), which the haproxy b64dec convertor doesn't >> appear to be able cope with. The result of > > Jonathan, > > It's not just padding, urlsafe base64 replaces '+' with '-', and '/' > with '_'.
You're right. I'd noticed those extra substitutions but, for some reason I'd assumed they were applied after decoding. Brain fart! > For now, I guess the easiest way would be to write a simple > converter in Lua, which just returns the original string, and send > payload somewhere for further processing. One nice thing about the JWT format is that it's unambiguously formatted as "header.payload.signature", so the payload can be trivially parsed out of a sacrificial header with a http-request replace-header copy-of-jwt [^.]+\.([^.]+)\..+ \1 ... or some such manipulation. Here, for clarity, I'm double-passing it through an abns@ frontend-backend-listen chain, hence the additional header and not a variable, as per your example. I think with your points and ccripy's sneaky (kudos!) padding insertion, I can do something which suffices for my current audit needs. I suspect you're right that a Lua convertor is probably the more supportable way forwards, however. Many thanks, both! J
