RestTemplate cannot support OAuth [SPR-6143]

[spring-projects-issues]

Brian Topping opened SPR-6143 and commented

Overview: OAuth works by a series of shared secrets and hashes with those secrets on the URI and it's query parameters. In order for RestTemplate to support this increasingly important protocol, a transport must allow access (ideally, structured access) to the parameters that must be hashed as a part of the protocol.

As it stands, RestTemplate cannot support OAuth. There are two major issues:

First: It was attempted to do this with a RequestCallback for GET method calls, but failed because the URLConnection is created before the RequestCallback has an opportunity to add the necessary additional query parameters. It seems only appropriate that RequestCallback should have r/w access to the URI before it is used to open a connection.

Second: Even if this were fixed for GET method calls, http://oauth.net/core/1.0a#rfc.section.9.1.1 states that request parameters are collected from three locations when calculating signature hashes:

• Parameters in the OAuth HTTP Authorization header (Authorization Header) excluding the realm parameter.
• Parameters in the HTTP POST request body (with a content-type of application/x-www-form-urlencoded).
• HTTP GET parameters added to the URLs in the query part (as defined by [RFC3986] (Berners-Lee, T., "Uniform Resource Identifiers (URI): Generic Syntax," .) section 3).

Unfortunately, because the request body of the POST method is an OutputStream, there is no way to inspect the body to find application/x-www-form-urlencoded data, parse it for parameters, and construct the Signature Base String.

Fixing the second problem highlights a need for structured body content renderers that can be modified before they are called to render when the connection is made. For instance, a basic BodyContentRenderer could write directly to the connection OutputStream (with no semantic difference than the current solution), and a more advanced one would emulate HTML form data, eventually rendering application/x-www-form-urlencoded data to the OutputStream, but not until the RequestCallback had an opportunity to modify the structured data of the form before it was rendered.

---

Affects: 3.0 M4

Issue Links:

• Introduce interceptors for RestTemplate [SPR-7494] #12152 Introduce interceptors for RestTemplate ("depends on")
• UriTemplate doesn't encode query parameters [SPR-8403] #13050 UriTemplate doesn't encode query parameters

4 votes, 3 watchers

[spring-projects-issues]

Brian Topping commented

I probably have the wrong priority on this, but the problem does block my use of RestTemplate.

[spring-projects-issues]

Juergen Hoeller commented

Indeed, this is not a blocker in the sense of the term as we're using it here. It's rather a serious gap in functionality that's worth looking at.

Juergen

[spring-projects-issues]

Arjen Poutsma commented

With the introduction of ClientHttpRequestInterceptors, I believe we can support OAuth. In fact, the Spring Social guys are already doing so :).

[spring-projects-issues]

Dave Syer commented

N.B. #13050 is related and seems to be converging on a resolution.

[spring-projects-issues]

Dave Syer commented

On second thoughts, maybe #13050 isn't all that relevant, because that is more specifically about placeholder replacements (the order is important there as well). Also note: Spring Security OAuth is using a custom ClientHttpRequestFactory to construct the query (available in Spring 3.0, unlike the new interceptor).