JWTs are not themselves base64url encoded

[bc-pi]

A signed JWT is always a a series of three base64url-encoded values separated by a period ('.') character. It is not itself base64url-encoded. So saying things like <base64-URL-encoded registration JWT> and Sec-Session-Response: <base64-URL-encoded JWT> are not really accurate and/or potentially misleading. In those contexts it could just say something like "the JWT" because JWT formatting and encoding is defined and unambiguous.

There's also an "application/jwt" media type that would be appropriate as the Content-Type in the example POST request to /securesession/startsession (rather than application/json which it has now).

Copies of the two examples mentioned herein are included below for posterity/convenience. (as I look at them, however, I can't help but wonder why the JWT is sent in the body with "startsession" and a header with "refresh"?)

POST /securesession/startsession HTTP/1.1
Host: auth.example.com
Accept: application/json
Content-Type: application/json
Content-Length: nn
Cookie: whatever_cookies_apply_to_this_request=value;

<base64-URL-encoded registration JWT>

POST /securesession/refresh HTTP/1.1
Sec-Session-Response: <base64-URL-encoded JWT>

[dickhardt]

To provide a little more background on @bc-pi comments, a JWT is the compact serialization (base64 URL encoded) of a JWS. There is also a JSON serialization format that I have never myself seen in the wild.

I agree also with Brian's comments around having the JWT in a header sometimes and a body sometimes. A key requirement in the design of JWT was that it could be included in an HTTP header without additional encoding (and also in a URL)

In my opinion, browser related protocols should "stay in their lane" and use headers rather than the body

[arnar]

Thanks for good suggestions! Agree that the current handwaving is potentially misleading. In all cases we mean the normal compact serialization.

Also agree we should be consistent on header vs body. Tbh I'm not totally sure where Sec-Session-Response came from, but Dick your feedback on staying with header is duly noted!

[kmonsen]

Yes, I will update to use headers. We went back and forth between body and header internally with the unfortunate result that we got one of each. Thank you for the feedback, will update.

[kmonsen]

One reason I personally think headers are better is that doesn't interfere with other body content.

[wparad]

But it's worth maybe a couple more words. "How Body". Will it handle JSON, XML, gRPC, or some other binary format.

While it is the one body thing, what happens when there is a second property or third property that we realize, oops we need this and it doesn't belong in the JWT. Then we are stuck. Unless the body is going to be plain unencoded application/json.

But since we are actually attempting to authorize the request, the authorization header already exists to send JWTs like this generated by the signer, that would be the most consistent with how many services validate incoming JWTs. If