documentation/manual/en/module_specs/Zend_Oauth-SecurityArchitecture.xml

   1 <?xml version="1.0" encoding="UTF-8"?>
   2 <!-- Reviewed: no -->
   3 <sect2 id="zend.oauth.introduction.security-architecture">
   4     <title>Security Architecture</title>
   5
   6     <para>
   7         OAuth was designed specifically to operate over an insecure <acronym>HTTP</acronym>
   8         connection and so the use of <acronym>HTTPS</acronym> is not required though obviously it
   9         would be desireable if available. Should a <acronym>HTTPS</acronym> connection be feasible,
  10         OAuth offers a signature method implementation called PLAINTEXT which may be utilised. Over
  11         a typical unsecured <acronym>HTTP</acronym> connection, the use of PLAINTEXT must be avoided
  12         and an alternate scheme using. The OAuth specification defines two such signature methods:
  13         HMAC-SHA1 and RSA-SHA1. Both are fully supported by <classname>Zend_Oauth</classname>.
  14     </para>
  15
  16     <para>
  17         These signature methods are quite easy to understand. As you can imagine, a PLAINTEXT
  18         signature method does nothing that bears mentioning since it relies on
  19         <acronym>HTTPS</acronym>. If you were to use PLAINTEXT over <acronym>HTTP</acronym>, you are
  20         left with a significant problem: there's no way to be sure that the content of any OAuth
  21         enabled request (which would include the OAuth Access Token) was altered en route. This is
  22         because unsecured <acronym>HTTP</acronym> requests are always at risk of eavesdropping, Man
  23         In The Middle (MITM) attacks, or other risks whereby a request can be retooled so to speak
  24         to perform tasks on behalf of the attacker by masquerading as the origin application without
  25         being noticed by the service provider.
  26     </para>
  27
  28     <para>
  29         HMAC-SHA1 and RSA-SHA1 alleviate this risk by digitally signing all OAuth requests with the
  30         original application's registered Consumer Secret. Assuming only the Consumer and the
  31         Provider know what this secret is, a middle-man can alter requests all they wish - but they
  32         will not be able to validly sign them and unsigned or invalidly signed requests would be
  33         discarded by both parties. Digital signatures therefore offer a guarantee that validly
  34         signed requests do come from the expected party and have not been altered en route. This is
  35         the core of why OAuth can operate over an unsecure connection.
  36     </para>
  37
  38     <para>
  39         How these digital signatures operate depends on the method used, i.e. HMAC-SHA1, RSA-SHA1 or
  40         perhaps another method defined by the service provider. HMAC-SHA1 is a simple mechanism
  41         which generates a Message Authentication Code (MAC) using a cryptographic hash function
  42         (i.e. SHA1) in combination with a secret key known only to the message sender and receiver
  43         (i.e. the OAuth Consumer Secret and the authorized Access Key combined). This hashing
  44         mechanism is applied to the parameters and content of any OAuth requests which are
  45         concatenated into a "base signature string" as defined by the OAuth specification.
  46     </para>
  47
  48     <para>
  49         RSA-SHA1 operates on similar principles except that the shared secret is, as you would
  50         expect, each parties' RSA private key. Both sides would have the other's public key with
  51         which to verify digital signatures. This does pose a level of risk compared to HMAC-SHA1
  52         since the RSA method does not use the Access Key as part of the shared secret. This means
  53         that if the RSA private key of any Consumer is compromised, then all Access Tokens assigned
  54         to that Consumer are also. RSA imposes an all or nothing scheme. In general, the majority of
  55         service providers offering OAuth authorization have therefore tended to use HMAC-SHA1 by
  56         default, and those who offer RSA-SHA1 may offer fallback support to HMAC-SHA1.
  57     </para>
  58
  59     <para>
  60         While digital signatures add to OAuth's security they are still vulnerable to other forms of
  61         attack, such as replay attacks which copy earlier requests which were intercepted and
  62         validly signed at that time. An attacker can now resend the exact same request to a
  63         Provider at will at any time and intercept its results. This poses a significant risk but it
  64         is quiet simple to defend against - add a unique string (i.e. a nonce) to all requests which
  65         changes per request (thus continually changing the signature string) but which can never be
  66         reused because Providers actively track used nonces within the a certain window defined by
  67         the timestamp also attached to a request. You might first suspect that once you stop
  68         tracking a particular nonce, the replay could work but this ignore the timestamp which can
  69         be used to determine a request's age at the time it was validly signed. One can assume that
  70         a week old request used in an attempted replay should be summarily discarded!
  71     </para>
  72
  73     <para>
  74         As a final point, this is not an exhaustive look at the security architecture in OAuth. For
  75         example, what if <acronym>HTTP</acronym> requests which contain both the Access Token and
  76         the Consumer Secret are eavesdropped? The system relies on at one in the clear transmission
  77         of each unless <acronym>HTTPS</acronym> is active, so the obvious conclusion is that where
  78         feasible <acronym>HTTPS</acronym> is to be preferred leaving unsecured
  79         <acronym>HTTP</acronym> in place only where it is not possible or affordable to do so.
  80     </para>
  81 </sect2>