Signpost is the easy and intuitive solution for signing HTTP messages on the Java platform in conformance with the OAuth Core 1.0a standard. Signpost follows a modular design, allowing you to combine it with different HTTP messaging layers. Click here for a list of supported HTTP libraries.
Signpost is a community effort and may be downloaded, modified, and redistributed under the terms of the Apache License version 2.
Signpost has been designed with several principal goals in mind:
Using Signpost is as simple as it could possibly get -- all actions are executed with only a few lines of code. For example, this is how you would sign a classic Java HTTP message using Signpost:
// create an HTTP request to a protected resource
URL url = new URL("http://api.example.com/protected")
HttpURLConnection request = (HttpURLConnection) url.openConnection();
// sign the request (consumer is a Signpost DefaultOAuthConsumer)
consumer.sign(request);
// send the request
request.connect();
Signpost exposes a minimalistic API designed for two purposes: Signing HTTP messages and requesting tokens from an OAuth service provider. Everything else is beyond the scope of the OAuth specification, and is thus left to the HTTP messaging layer, where it belongs.
For more exhaustive examples, please refer to GettingStarted.
Signpost tries to be as unobtrusive as possible. Unlike other implementations, Signpost does not wrap the entire HTTP layer and hides its features from the client. Instead, you simply pass an HttpRequest object to it, and Signpost will sign the message using the credentials it was configured with.
This means that all the power and flexibility of the underlying HTTP engine is still at your fingertips!
Since version 1.1, Signpost comes in modules. Apart from the core module, which you always need, you can download additional modules to support other HTTP messaging libraries than the one coming with the standard Java platform (which would be java.net.HttpURLConnection).
Apart from HttpURLConnection, Signpost currently has modules for Apache Commons HTTP version 4, and Jetty HTTP Client version 6.
Simplicity doesn't come free. Thus, Signpost currently makes certain assumptions to reduce the complexity of both the implementation and the API.
- Message signing using public key encryption (as per section 9.3) is currently unsupported. Message signing using the PLAINTEXT and HMAC-SHA1 methods is supported, however.
- Accounting for existing OAuth parameters in the Authorization header (as per sec. 5.4.1) is currently unsupported (i.e. anything in the Authorization header prior to message signing will not become part of the signature)
- Signpost currently does not support writing OAuth protocol params to the WWW-Authenticate header field
I believe that even with those restrictions in place, Signpost will work for the majority of its users. Trading in rarely used features for more simplicity and ease of use was a design decision. If that doesn't work for your setup, Signpost is probably not the best choice for you.
Signpost is not thread safe and probably will never be. Signpost objects are very lightweight, so you are adviced to create an OAuthConsumer and OAuthProvider for every thread in your application that must send signed HTTP requests.
Signpost is already used in several applications running on Android, Google's software stack for mobile devices. In fact, Signpost has already signed thousands of HTTP requests at this very moment, as it is an integral part of Qype Radar, our geo-sensitive mobile application for Android that finds the best places near you.
If neither Signpost nor the OAuth service providers out there would be buggy, then Signpost would work with all of them. That's quite an optimistic expectation though, so on a slightly more conservative note, here's a list of service providers that have been tested to work with Signpost:
Please use the Signpost Google Group for questions, feedback and discussion.