Page History

...

where 'ts' attribute is used to pass a timestamp value.

...

Encrypted tokens

Typically, the tokens are persisted in the storage. The alternative approach is to completely encrypt the token state and return the encrypted representation back to a client: the processing time to do with the encryption and decryption might increase but the server wins on avoiding the DB / storage lookups.    

CXF 3.0.0-milestone2 introduces the utility support for encrypting the state of BearerAccessToken and RefreshToken.

The tokens can be encrypted and decrypted with symmetric (secret) keys or certificates (public and private keys) and the combination of certificates and secret keys.

ModelEncryptionSupport can be used to encrypt the tokens using the custom serialization format. EncryptionUtils can be used directly if the alternative serialization format is preferred.  

Note that ServerAuthorizationGrant and Client can also be encrypted.

Using Secret Keys

The simplest strategy is to encrypt and decrypt the tokens with the symmetric/secret keys. Every new token can be encrypted with a unique secret key or all of them can be encrypted with a single secret key. The utilities provide few methods for creating secret keys with the default and advanced properties, in addition there are many examples around on how to create the keys with the specific properties.

For example, see EncryptingDataProvider:

{code:java}

SecretKey key = EncryptionUtils.getSecretKey();

// create a new token, encrypt its state and return

ServerAccessToken token = new BearerAccessToken(client, 3600L);

String encryptedToken = ModelEncryptionSupport.encryptAccessToken(token, key);

token.setTokenKey(encryptedToken);

return token;

// decrypt a token given a token key

ModelEncryptionSupport.decryptAccessToken(this, encryptedToken, key);

{code}

Using Certificates

Working with the certificates to encrypt the state is similar to working with the symmetric keys. Please check the code examples in EncryptionsUtilsTest.

One needs to load a Certificate, use its public key to encrypt and the private key to decrypt. using the certificate to encrypt the whole serialized token representation might be marginally slower compared to using the symmetric keys, however given that the sequence is about 300+ characters maximum the performance can be reasonable.

Using Certificates and Secret Keys

The other approach is to generate a secret key, use this key to encrypt the token and then use the certificate to encrypt the key. The encrypted token and the actual encrypted secret key can be returned to the client as a token parameter, for example, as a 'key' parameter. This 'key' parameter will need to be returned to the OAuth2 server, via the HTTP header or the custom authorization scheme. The data providers using this mechanism will need to implement AccessTokenValidator and decrypt the encrypted key with the private certificate key, and decrypt the token with the decrypted secret key. Please check the code example in EncryptionsUtilsTest.

Custom tokens

If needed, users can use their own custom token types, with the only restriction that the custom token type implementations have to extend org.apache.cxf.rs.security.oauth2.common.ServerAccessToken.CXF implementations of Bearer and Access token types can also be extended if required. For example, typically the access token data will be persisted in the database. One possible option is to experiment with actually encrypting the state of the token within the token id itself and returning it to the client and then decrypting it when OAuthDataProvider is requested to get ServerAccessToken representation of the current token identifier.The cost of encrypting and decrypting will add up to the processing time - however the provider will not be actually responsible for storing the access token details which can start making a difference with a high number of clients.

Simple Tokens and Audience

...