...

Introduction

New:

• Ehcache, JCache and JCache JPA2 OAuthDataProviders can represent access tokens in JWTJPA2 OAuthDataProvider improved
• Client Certificate Authentication and Token Binding is supported
• DynamicRegistrationService addedis enhanced
  
  

CXF provides the implementation of OAuth 2.0. See also the JAX-RS OAuth page for information about OAuth 1.0.

...

Starting from CXF 3.1.8 some of CXF OAuthDataProvider implementations (EhCache, JCache and JCache JPA2 based) support Access Token representations in JWT. This means that ServerAccessTokens created by data providers are converted to a sequence of JSON JWT claims and then JWS signed and/or JWE encrypted.

...

For example, here is how one can configure an Ehcache or JCache based provider one of CXF data providers to use JWT:

<bean id="oauthProvider" class="org.apache.cxf.systest.jaxrsrs.security.oauth2.grants.commoncode.OAuthDataProviderImplDefaultEHCacheCodeDataProvider">
       <property name="useJwtFormatForAccessTokens" value="true"/>
</bean>

...

Additionally, in order to sign and/or encrypt, this provider can be injected with an instance of OAuthJoseJwtProducer or AccessTokenService endpoint where this provider is registered can be configured as follows:

...

<jaxrs:server id="oauthServer1" address="https://localhost:${testutil.ports.jaxrs-oauth2-serviceJwt}/services">
 <jaxrs:serviceBeans>
   <ref bean="tokenService"/>
</jaxrs:serviceBeans><!-- Sign -->
<jaxrs:properties>
 <entry key="rs.security.signature.properties" value="org/apache/cxf/systest/jaxrs/security/alice.rs.properties"/>
 <entry key="rs.security.signature.key.password.provider" value-ref="keyPasswordProvider"/>
 </jaxrs:properties>
 </jaxrs:server>

Note that in this case Ehcache, JCache and JCache JPA2 providers will still persist the complete ServerAccessToken representations - once JOSE sequence is created it becomes a new tokenId of the current ServerAccessToken, with the original tokenId becoming a JWT 'jti' claim.

The main advantage is that such tokens can be introspected locally at the resource server side, thus avoiding the remote token validation calls.

One can configure the providers (Ehcache and JCache only at the moment) to persist access tokens only as these newly created JOSE sequences:

...

Only a JOSE sequence representing a given ServerAccessToken will be persisted. The providers will recreate ServerAccessToken from this sequence when the token is needed by the runtime, while requiring much less storage to keep such tokens.

In this case, if it is preferred, one can further optimize it not to even store these secure string token representations - however the major downside is that it will be impossible to manage such tokens from the administration consoles due to no record of such tokens will be available in the storage.

Resource server (RS) will need to make a decision how to validate this JWT token. It can continue validating it remotely with AccessTokenValidationService or TokenIntrsopectionService (see below for more info about these services) or if RS has an access to the keys used to sign/encrypt JWT then it can use a local JWT validation, example:

...

If a Basic authentication scheme is used and neither the container or filter has authenticated the client AccessTokenService will request a Client from the data provider and compare the Client's secret against the password found in the Basic scheme data. org.apache.cxf.rs.security.oauth2.provider.ClientSecretVerifier is available starting from CXF 3.0.3 to support Clients saving only password hashes. Its org.apache.cxf.rs.security.oauth2.provider.ClientSecretHashVerifier (calculates a SHA-256 password hash and compares it with the Client's secret) or custom implementations can be registered with AccessTokenService.

Please see JAXRS OAuth2 Assertions section for more information on how it may work.

Client Certificate Authentication

If a 2-way TLS is sued used to authenticate a client and Client has a Base64 encoded representations of its X509Certificates available in its "applicationCertificates" property then AccessTokenService will do the additional comparison of these certificates against the ones available in the current TLS session.

Please see JAXRS OAuth2 Assertions section for more information on how it may workNew: Mutual TLS Profiles for OAuth2 Clients is completely supported since CXF 3.1.12. Note some parameters used in this draft may change.

User Session Authenticity

...