Re: Java EE Security.next and JWT (JSON Web Tokens)


Will Hopkins
 

In terms of OAuth2, I don't think it's a case of standing up an authorization server, it's more a case of being able to consume OAuth2 access tokens, as distinct from OpenID Connect identity tokens. Support for access tokens, especially (or perhaps exclusively) for JAX-RS applications, would presumably be very popular. Access tokens bring with them a certain amount of complexity, though, as they involve two distinct "subjects" (application client, resource owner) and an authorization model involving claims (scopes) asserted by the authorization server, that the resource server must honor. Since claims are app-specific, there's also an implied requirement for out-of-band configuration exchange with the authorization server, which would be useful to automate in some way (maybe something like SAML2 metadata?), and resource servers/apps probably need some type of configuration to describe the format/content of tokens they're willing/able to consume.

On 07/11/2017 05:43 PM, David Blevins wrote:
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.



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

Join javaee-security-spec@javaee.groups.io to automatically receive all group messages.