Re: Java EE and JWT (JSON Web Tokens)

David Blevins

A few thoughts:

- Crypto: It’s only the extended policy files (JCE) that are restricted. The JVM has rsa-sha256 built-in, so we’re good. JWTs support anything, but we’d have an opinionated perspective and say “the server must support verifying an RSA-SHA256 signed JWT”. Anything else could be vendor specific (aka open to being a requirement later).

- OAuth2: I’m not sure it makes sense for us to “include” OAuth 2.0. Specifically, the app server issuing OAuth 2.0 access tokens is not a pattern I see anyone doing or on the horizon. What I see is people propping up OAuth 2.0 gateways in front of their LDAP server. These OAuth 2.0 servers are issuing JWT tokens with a “snapshot” of LDAP data, they are signed by the OAuth 2.0 Gateway. More and more the server is not the one performing the token grant with the Gateway and obtaining the JWT access token. It’s often being done by the browser via javascript or the mobile device, after which point the token is passed with all calls. The app server needs only to check the signature to verify the JWT when a request comes in with an "Authentication: Bearer <the jwt access token>” header. This can be done with a RSA public key provided by the OAuth 2.0 Gateway.

The short version, IMO, our job is really just to require the server can verify the token. Ideally with an additional requirement that the server support being able to map fields from the json map (the token’s payload) to answer “isCallerInRole” and “getCallerPrincipal” calls.

I think if we got that far, we’d be good for several years.

David Blevins

On Jul 11, 2017, at 10:59 AM, Will Hopkins <> wrote:

It's indeed to late to add JWT support, or OpenID Connect, or OAuth2. ;)

Regarding encryption, wouldn't it be feasible to depend on crypto libraries without actually delivering them? I.e., say, "This API and RI works when the Xyz crypto lib is present, compatible versions are X, available from Y. Please obtain these libraries before attempting to use this JSR"? It would probably be fairly straightforward to keep crypto out of the API itself.


On 07/11/2017 09:36 AM, Werner Keil wrote:
Actually JetBrains mentioned something like OpenID only, which they hopefully mean "OpenID Connect" since OpenID in its original form is long dead?;-)

I also abstained on JSR 310 both in the Public Draft ( and PFD. Due to issues, of which only the lack of ISO 8601 standard support was properly resolved.
While circular dependencies between TemporalAmount and RI element Duration were not resolved (on the ohter hand, the DateTimeFormatter returns only API level abstract Temporal types, not concrete final classes, so it is quite inconsistent and most importantly makes an independent implementation totally impossible)

After talking to Antoine at JavaOne he said, that server-side OAuth or OpenID Connect support would be very hard to accomplish in the brief timeframe EE 8 was given.
Arjan also highlighted, that OAuth, JWT, etc. depend on cryptography and the list of countries, that do not allow cryptography is rather long:
(I gave a talk on JSR 321, Trusted Java at JavaOne Russia, but I did not do a live demo because using a TPM chip is illegal there;-)

Therefore adding crypto-libraries to Soteria/Glassfish by default could mean a lot of trouble for this JSR and products based on it.
Not sure, if they ever can be official parts of the RI in the future, or this will be entirely up to 3rd party vendors and open source projects.

That is among the reasons, why "security-samples" and similar extensions are probably as important as Soteria itself, if not more.

Kind Regards,
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

Join to automatically receive all group messages.