It&#x27;s probably the biggest problem with pairing HTTP(S)&#x2F;1.1 and REST. TLS&#x2F;SSL will require a session that is much more &quot;bound&quot; (entangled?) -- and really would be the sane place to keep track of authentication&#x2F;id bindings (Who is the client?) -- and use as a basis for authorization (What does <i>this</i> client have access to). But because of the &quot;bolt-on&quot; nature of TLS, we get things like TLS terminating proxies&#x2F;load-balancers etc, and a lot of passing flags in headers (ProyxN confirms that it&#x27;s relaying over plain-text HTTP on the (assumed to be) secure internal network, on behalf of clientX that&#x27;s connected over TLS <i>and</i> has been authenticated...).<p>The &quot;simple&quot; answer is to have client-certificates, and allow a client access directly to an application server over TLS, <i>or</i> use a secure transport (eg: IPSec), and just use standard HTTP auth on every pass (which AFAIK never was extended to use some form of standardized token, so one&#x27;s left with sending the actual login&#x2F;password pair every time).<p>The sane compromise is to just use encrypted cookies -- but <i>they</i> are also <i>bolt on</i> solutions.<p>The problem is that essentially one needs encryption to ensure secure sessions, which essentially boil down to authenticating the client to the server, and the server to the client, and forming some kind of session (typically DH for a symmetric session key).<p>For a long while, encryption was <i>really</i> expensive compared to the db lookup and template render that &quot;every&quot; web application did -- and so we&#x27;ve ended up with a mess of &quot;best practices&quot; which aren&#x27;t very good at all (and not a very good way of moving from REST-that-trusts-plaintext-ip to REST-and-also-secure).<p>With HTTP&#x2F;2 it looks like things are moving towards making the transport-protocol part do the things it should -- track the session, and secure the session. Still doesn&#x27;t do a good job of <i>authenticating</i> the client in any meaningful way, but it should simplify some of the assumptions that are necessary to build a secure(ish) system.