First, the JWT is base64-encoded. Actually the structure of a signed JWT is three segments of base64-encoded data, joined with dots. Something like: xxxxxx.xxxxx.xxxxx , where each xxxxx is a base64-encoded segment. Normally, you should pass the JWT that way. This is the format used by libraries that produce JWT; this is the format used by JWT-dispensing services like Ping and Azure AD and Google Signin.
As for how to pass it, a JWT can act as a bearer access token, in which case passing it in the Authorization header is probably appropriate:
Authorization: Bearer xxxxx.xxxxx.xxxxx
In this usage, the JWT is an OAuth token. Therefore it's not a question of "JWT Vs OAuth". For more on this, see this question and answer.
In some other cases, a JWT is an identity token. It asserts the identity of a person or an app. For example, if you want to obtain an access token for Google Stackdriver, you must send in a request to the Google token dispensary that looks like this:
POST https://www.googleapis.com/oauth2/v4/token
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=JWT_GOES_HERE
...and in this case the JWT asserts the identity of the client, and is passed as a form parameter. Here, as usual, the JWT is the dot-concatenated set of three base64 pieces. The difference in convention for passing the JWT from the access token case makes sense. This latter example is RFC7523, and the JWT is an identity token, not an access token.
You can build API Proxies in Apigee Edge that conform to either model of course. For info on implementing RFC7523 in Apigee Edge, See here.
So the bottom line is, you can accept your JWT any way that seems appropriate. There are conventions established that might make it easier on developers. Specifically, if the JWT is an access token, use the Authorization header. If the request is a request-for-token conforming to RFC7523, use a form parameter.
LinkedIn
Twitter
