Cause:
When the user name contains an "@" character Report Builder is creating the OAuth signature using "https://clmserver/jts/users/user%40ibm.com" while JTS is verifying the OAuth signature based on "https://clmserver/jts/users/user@ibm.com".
Since the two URLs are different (%40 vs @) the OAuth signature validation failed.

The problem is described here:
http://publib.boulder.ibm.com/httpserv/ihsdiag/plugin_questions.html#pluindecode

-----
Why does the WAS Plugin send a different encoding then the incoming request used?

By default, the WAS Plugin uses the URL that has been decoded by Apache and split into various sub-components. It can then re-encode the components in unexpected ways. After PM31189, you can have the Plugin start with the URL the way the client encoded it and do no further decoding or encoding. The apache environment variable websphere-nocanon turns this feature on.

If the character you're having trouble with is '/' (%2f), you'll also need the IHS portion of PM31189 to pass through %2f un-decoded with AllowEncodedSlashes NoDecode.
-----

Solution:
1. Navigate to the installation directory for your IBM HTTP Server.
2. Open conf\httpd.conf in an editor.
3. In the Global section (Section 1) of the file, add this entry:
SetEnv websphere-nocanon 1
4. Restart your web server.

Note:
This setting is also mentioned in the CLM documentation for the RQM ETL:
http://www-01.ibm.com/support/knowledgecenter/SSYMRC_6.0.0/com.ibm.jazz.install.doc/topics/t_config_reverse_proxy_ihs.html?lang=en