From 6f8855cd16fb5a91c847db3ef255223d3744656c Mon Sep 17 00:00:00 2001 From: Fabio Turizo Date: Thu, 26 Nov 2020 16:28:44 -0500 Subject: [PATCH] Merge pull request #115 from fturizo/FISH-651_Allow_Disable_Typ_Claim_Validation FISH-651 Documented new changes for disabling JWT type verification --- .../pages/documentation/microprofile/jwt.adoc | 21 ++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/docs/modules/ROOT/pages/documentation/microprofile/jwt.adoc b/docs/modules/ROOT/pages/documentation/microprofile/jwt.adoc index f2bc2e87..dc9dbf50 100644 --- a/docs/modules/ROOT/pages/documentation/microprofile/jwt.adoc +++ b/docs/modules/ROOT/pages/documentation/microprofile/jwt.adoc @@ -146,7 +146,6 @@ This properties file should contain the key `accepted.issuer` with as value the === Namespaced claims configuration - Authentication services (like https://auth0.com/docs/scopes/current/custom-claims[auth0], https://connect2id.com/products/server/docs/config/claims-mapping[connect2id]) offer the possibility to add custom claims to JWT tokens but also enforce a namespaced format to avoid possible collisions with standard OpenID Connect claims. @@ -175,6 +174,26 @@ Then the JSON Parser search for namespace prefixed claims, remove the namespace ==== *custom.namespace* When the `custom.namespace` property is set, it will always take precedence over the default namespace and be used instead. +=== Disabling Type Claim Verification + +_Since Payara Platform 5.2020.7_ + +The MicroProfile JWT Authentication specification currently mandates that the type claim (`typ`) of any authorization token parsed by the container is present and is set to the `JWT` value. However, the current RFC document (https://tools.ietf.org/html/rfc7519[RFC 7519]) that defines the JWT standard states that this claim is **optional**: + +> 5.1. "typ" (Type) Header Parameter +> +> The "typ" (type) Header Parameter defined by [JWS] and [JWE] is used by JWT applications to declare the media type [IANA.MediaTypes] of this complete JWT. This is intended for use by the JWT application when values that are not JWTs could also be present in an application data structure that can contain a JWT object; the application can use this value to disambiguate among the different kinds of objects that might be present. +> +> ... +> +> Use of this Header Parameter is OPTIONAL. + +For this reason, some third-party token issuers may generate tokens that are not compatible with the MicroProfile JWT specification. The Payara Platform allows to set this verification off, so you can use the `disable.type.verification` custom property and set its value to `true` to this effect. + +NOTE: This property has to be defined in the `payara-mp-jwt.properties` configuration file described in the previous section. + +IMPORTANT: Keep in mind that tokens which are missing their type claim and are propagated to other services running on other Eclipse MicroProfile runtimes might be rejected, as the specification mandates the inclusion of the claim. + == Activating JWT Authentication An application activates the JWT authentication mechanism and identity store by annotating a class in the application, for instance, the JAX-RS `Application` class, with `@LoginConfig(authMethod = "MP-JWT")`.