base64url format View as Markdown

I've been working with JWTs lately and that means working with Base64URL
format. (Ref: https://www.rfc-editor.org/rfc/rfc4648#section-5 )
This is essentially the same thing as normal Base64, but instead of '+' and
'/', it uses '-' and '_', respectively. It also allows leaving off the
training '=' padding characters.

So far, I've just been including polyfills like this:

function base64url_decode(string $str): string {
return base64_decode(str_pad(strtr($str, '-_', '+/'), (4 -
(strlen($str) % 4)) % 4, '='));
}

function base64_encode(string $str): string {
return rtrim(strtr(base64_encode($str), '+/', '-_'), '=');
}

These work fine, but they create a LOT of string copies along the way which
shouldn't be necessary.
Would anyone mind if skipped RFC and just added base64url_encode() and
base64url_decode() to PHP 8.3?

Can hold a vote if anyone objects, but this seems fairly non-controversial.

IMO, go with a PR first. If that is controversial, an RFC can still be
done.

I, personally, would be more interested in base32, but that's another story.

--
Christoph M. Becker

I'm in support of such a feature, but would strongly advocate for an
additional parameter to flag whether or not to include the trailing =
pad. The trailing pad is optional according to RFC 4648, so I think
leaving it off by default would be the ideal use case, but an optional
include_padding flag or something along those lines would be helpful.

I've been working with JWTs lately and that means working with Base64URL
format. (Ref:https://www.rfc-editor.org/rfc/rfc4648#section-5 )
This is essentially the same thing as normal Base64, but instead of '+' and
'/', it uses '-' and '_', respectively. It also allows leaving off the
training '=' padding characters.

So far, I've just been including polyfills like this:

function base64url_decode(string $str): string {
return base64_decode(str_pad(strtr($str, '-_', '+/'), (4 -
(strlen($str) % 4)) % 4, '='));
}

function base64_encode(string $str): string {
return rtrim(strtr(base64_encode($str), '+/', '-_'), '=');
}

These work fine, but they create a LOT of string copies along the way which
shouldn't be necessary.
Would anyone mind if skipped RFC and just added base64url_encode() and
base64url_decode() to PHP 8.3?

Can hold a vote if anyone objects, but this seems fairly non-controversial.

-Sara

--
Security Principles for PHP Applications
https://www.phparch.com/books/security-principles-for-php-applications/
*Eric Mann

• Tekton
  *PGP:*0x63F15A9B715376CA https://keybase.io/eamann
  *P:*503.925.6266
  *E:*eric@eamann.com
  eamann.com https://eamann.com
  ttmm.io https://ttmm.io
  Twitter icon https://twitter.com/ericmann LinkedIn icon
  <https://www.linkedin.com/in/ericallenmann/

Hi

I've been working with JWTs lately and that means working with Base64URL
format. (Ref: https://www.rfc-editor.org/rfc/rfc4648#section-5 )
This is essentially the same thing as normal Base64, but instead of '+' and
'/', it uses '-' and '_', respectively. It also allows leaving off the
training '=' padding characters.

With JWTs you likely also want a constant time encoder that is not
susceptible for cache-timing leaks [1]. For this reason
https://github.com/paragonie/constant_time_encoding is a most-have
dependency for my projects and I generally use the functions of that
library by default, unless there is a reason not to (high performance
required). That library also includes a b32 implementation that cmb wished.

There's also
https://www.php.net/manual/en/function.sodium-bin2base64.php which is
constant-time and supports b64url, unfortunately it's not guaranteed to
be available.

Best regards
Tim Düsterhus

[1] It's likely more important for encrypted tokens, than only for
signed ones.

I've been working with JWTs lately and that means working with Base64URL
format. (Ref: https://www.rfc-editor.org/rfc/rfc4648#section-5 )
This is essentially the same thing as normal Base64, but instead of '+' and
'/', it uses '-' and '_', respectively. It also allows leaving off the
training '=' padding characters.

So far, I've just been including polyfills like this:

function base64url_decode(string $str): string {
return base64_decode(str_pad(strtr($str, '-_', '+/'), (4 -
(strlen($str) % 4)) % 4, '='));
}

function base64_encode(string $str): string {
return rtrim(strtr(base64_encode($str), '+/', '-_'), '=');
}

These work fine, but they create a LOT of string copies along the way which
shouldn't be necessary.
Would anyone mind if skipped RFC and just added base64url_encode() and
base64url_decode() to PHP 8.3?

Should these be new functions, or options to base64_encode instead? I'd guess base64_decode could just accept both?

cheers
Derick

I've been working with JWTs lately and that means working with Base64URL
format. (Ref: https://www.rfc-editor.org/rfc/rfc4648#section-5 )
This is essentially the same thing as normal Base64, but instead of '+' and
'/', it uses '-' and '_', respectively. It also allows leaving off the
training '=' padding characters.

So far, I've just been including polyfills like this:

function base64url_decode(string $str): string {
return base64_decode(str_pad(strtr($str, '-_', '+/'), (4 -
(strlen($str) % 4)) % 4, '='));
}

function base64_encode(string $str): string {
return rtrim(strtr(base64_encode($str), '+/', '-_'), '=');
}

These work fine, but they create a LOT of string copies along the way which
shouldn't be necessary.
Would anyone mind if skipped RFC and just added base64url_encode() and
base64url_decode() to PHP 8.3?

Can hold a vote if anyone objects, but this seems fairly non-controversial.

-Sara

It sounds to me like there's enough discussion to be had on the How to warrant a formal RFC. I get the sense once the bikeshedding is done it will pass, but it's going to need the discussion/review.

--Larry Garfield