The PLAINTEXT signature method was explicitly
design to be used over secure channels, which allows the secrets to be transmitted
in plain text with each request without the risk of being captured and exploited.
Unlike the other two signature methods, PLAINTEXT does not require the construction
of the Signature Base String. Instead, it sets the signature value to the concatenated
values of the client secret and token secret, separated by
an '&' character, even if either secret is empty (per
The OAuth parameters and request parameters are collected together in their raw,
pre-encoded form. The parameters are collected from three locations: the
query element (as defined by
RFC 3986 section 3
), the OAuth 'Authorization'
(excluding the 'realm' parameter), and parameters
included in a single-part 'application/x-www-form-urlencoded' POST body
(as defined by
). The parameter locations are more relevant to the server
as it needs to extract them from the incoming client request. The client should
have all the parameters in their separated and pre-encoded form as it builds the
All text parameters are UTF-8 encoded
(per section 3.6
data is not directly handled by the OAuth specification but is assumed to be stored
in an 8bit array which is not UTF-8 encoded. This step may not have any effect if
the parameters are only using the ASCII
After UTF-8 encoding, the parameters are
) in a specific way that is often not fully compatible with existing
URL-encoding libraries. Developers should check the details of their libraries to
ensure full compliance. Throughout the specification, great effort has been made
to reuse as much existing code as possible but when variation in implementation
were found, the specification provides detailed instructions to avoid interoperability
issues. All the unreserved characters (letters, numbers, '-', '_', '.', '~') must
not be encoded, while all other characters are encoded using the %XX format where
XX is an uppercase representation of the character hexadecimal value:
The parameters are sorted (per
) first based on their encoded names, and if equal, based on
their encoded values. Sort order is lexicographical byte value ordering which is
the default string sort method in most languages, and means comparing the byte value
of each character and sorting in an ascending order (which results in a case sensitive
sort). It is important not to try and perform the sort operation on some combined
string of both name and value as some known separators (such as '=') will
cause the sort order to change due to their impact on the string value.
Once encoded and sorted, the parameters are concatenated together into a single
string. Each parameter's name is separated from the corresponding value by an
'=' character (even if the value is empty), and each name-value pair is separated
by an '&' character (per section
). This method is similar to how HTML form data is encoded in 'application/x-www-form-urlencoded
but due to the specific encoding and sorting requirements, is often not fully compatible
with existing libraries.
After the parameters have been normalized, the other request elements are processed.
While the web is built on URLs, the HTTP protocol uses the data in pieces. URLs
are constructed from various elements, and take the general form of scheme://authority:port/path?query#fragment
as both host name and port but for simplicity, this tutorial
will define them separately). The scheme
are used to
establish the desired connection, the authority
is used in the 'Host'
header and to connect to the Service Provider, and the path
parts are used in the request itself (the fragment
is used locally by the
browser and is not transmitted with the request).
The request URL is normalized (per
) as scheme://authority:port/path
as the query
is already included in the list of parameters and the fragment
is excluded. The
must be in lowercase, and the port
must be present except for the default HTTP(S) ports which must be omitted ('80'
is omitted when the scheme
is 'http' and '443' is omitted
when the scheme
is 'https'). The path
must retain its
case as some platforms are case-sensitive. The HTTP request should include the 'Host'
header with the exact same host name used to create the normalized URL string. Developers
should verify with the Service Provider that it does not require any special handling
of the URL.
To complete the creation of the Signature Base String the input to the signature
algorithm all the request pieces must be put together into a single string. The
HTTP method (such as GET, POST, etc.) swhich is a critical part of HTTP requests
is concatenated together with the normalized URL and normalized parameters. The
HTTP method must be in uppercase and each of these three pieces is URL-encoded (as
defined above) and separated by an '&' (per
). For this request, the Signature Base String is:
The HMAC-SHA1 signature method uses the two secrets client secret and token
secret as the HMAC-SHA1 algorithm key
. To construct the key, each secret
is UTF8-encoded, URL-encoded, and concatenated into a single string using an '&'
character as separator even if either secret is empty (per
). Libraries should not assume the secrets are in plain ASCII
text and ensure proper UTF-8-encoding and URL-encoding prior to concatenation.
With the Signature Base String as the HMAC-SHA1 text
and concatenated secrets
, the client generates the signature (per
). The HMAC-SHA1 algorithm will generate an octet string as
the result. The octet string must be base64-encoded with '=' padding (per
RFC 2045 section 6.8
The RSA-SHA1 signature method uses the RSA Private Key to sign the value of the
Signature Base String by the client and uses the RSA Public Key to verify the
authenticity of the signature by the server. The Signature Base String
is signed using the S = RSASSA-PKCS1-V1_5-SIGN (K, M)
(per RFC 3447 section 8.2.1
is the client's RSA private key, M
the Signature Base
String, and S
is the result signature. The RSA-SHA1 algorithm will generate
an octet string as the result. The octet string must be base64-encoded with '='
padding (per RFC 2045 section