Eclipse User Storage Service SDK 1.1.0 Release Review

End Date of the Review Period

Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.




The  USS SDK is a Java API to interface with the Foundation-hosted User Storage Service from an Eclipse workspace. The SDK handles login/authentication, session management and storage/retrieval of data.

The USS SDK was originally created by the Oomph project and released as USS SDK 1.0.  The USS SDK was subsequently promoted as a full technology project.  Version 1.1 deprecated the login/password ('session') based authentication mechanism in favour of a new OAuth-based approach supported by the Foundation.  The session-based mechanism will be removed in USS SDK 2.0.

The USS SDK has documentation on the Eclipse Wiki.

Architectural Issues

Some contorsions were required to support both the now-deprecated "session"-based authentication and the newer OAuth-based mechanism.  The relevant code can be refactored and simplified once the session-based code is removed.

The USS SDK attempts to separate runtime and UI code.  But OAuth authorization is a mix and the two cannot be untwined.

Security Issues

Our approach exposes the OAuth Client Secret: To simplify the user experience, the USS SDK uses the Authorization Code grant flow, where the OAuth client (the consumer of the USS SDK) provides a Client ID and Client Secret, rather than the Implicit flow which only requires the Client ID. The Authorization Code flow provides clients with a time-limited access token, a nonce that must be provided on each request, and a refresh token, which allows obtaining new access tokens. Clients using the Implicit flow only receive time-limited authorization tokens and do not receive a refresh token

The Authorization code flow is normally intended for server-style applications where the Client Secret can be kept secret. Eclipse plugins are more akin to mobile apps, as their compiled bytecodes are open to introspection to a determined attacker.  But ultimately the implificit flow results in a poorer user exprience as the user must periodically re-affirm their authorization requests for the plugin to obtain a new access token (typically access tokens expire after an hour).  For a mobile app, which is used periodically, but most Eclipse plugins will be long-lived.

As the USS is not suited to store private or confidential information, and user data is intended to be shared, the need for confidential client secrets is moot.  And thanks to a contribution from Eike Stepper, and further improved by Carsten Reckord, we also provide a means to embed OAuth Client IDs and Secrets in a lightly-encrypted manner that can be committed to source repository. It adds a little bit of friction to an attempted crack.


Non-Code Aspects

User documentation, primarily an Eclipse Wiki page, is admittedly sparse.  The REST protocol is documented, but has not been published by the Eclipse Foundation.

Usability Details

OAuth authorization requires logging into the Eclipse Foundation web site, and is done through an internal web browser.


The USS SDK does not really have a user community.  The consuming projects are known to us and provide fixes and feedback on missing features.