Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Craig, great question. I am no expert, but have <a href="http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/" rel="noreferrer">thought a lot about this</a>, so a few thoughts.</p> <p>Assuming we have to code against the lowest-common denominator, and using your requirement list (all 4 items) as my design seed, I would say the following:</p> <ol> <li><strong>No SSL</strong> - Since you cannot guarantee SSL, you will have to go with a public/private key HMAC design. Let's just assume all traffic is over HTTP and is infinitely sniffable, which means you cannot transport any secure tokens or signing keys at any point over the wire to the caller, which means they need them already, which means a private signing key a-la something like what AWS does (or 2-legged OAuth or what I outlined in that article above).</li> <li><strong>No Replay</strong> - Using a nonce to block replay doesn't require it be generated by the server, you can use any value here. The nonce just needs to be unique, needs to be included in your HMAC calculation (signature) and the server needs to remember it. For example, generate a UUID as a nonce on the client, sign the request, send it across to the server: <code>?sig=&lt;a mess of chars&gt;&amp;args=&lt;more stuff&gt;&amp;nonce=f81d4fae-7dec-11d0-a765-00a0c91e6bf6</code> -- the server will record <code>f81d4fae-7dec-11d0-a765-00a0c91e6bf6</code> as processed and never allow it to be used again. You can probably safely expire these from the DB after a reasonable amount of time (month? depends on velocity/usage/etc). TIP: This is a <em>perfect</em> use-case for using Redis SETs and the <a href="http://redis.io/commands/sismember" rel="noreferrer">SISMEMBER command</a>.</li> <li>(see #2, combined answer)</li> <li>The request <strong>must</strong> be signed by the sender in its entirety. The key to understanding "what needs to get signed" is as simple as: anything you DON'T include in the HMAC (signature) calculation can be manipulated by a man-in-the-middle (MITM). Everything included in the sig is secured and CANNOT be changed without the sig check failing. This is why the OAuth specs (both of them) have pedantic rules about byte-ordering arguments, and how to append them and how to combine them, but you sign the <em>entire</em> request. Some APIs say something as simple as "take the entire query string, and sign it" -- but sometimes you get too much in that signature, like the domain name or endpoint that you might not want in there and need to change it in the future (or maybe you do, you're call).</li> </ol> <p>Just so you know, the thing that makes secure API design <em>instantly</em> painful is the moment you don't require HTTPS for all communication. As soon as you do that, you have to turn to solutions like HMAC's/signing requests and nonce's. If your communication with the sever is secured over HTTPS and both can trust each other, life gets much better and you can do things like simple basic auth and just give the server an API_KEY with every request to identify who (or what) is making the request.</p> <p>Hope that helps! It seems you've looked into this quite a bit already, so my apologies if you already knew all this and it didn't help.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload