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 implicit flow results in a poorer user experience 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.