Wednesday, October 09, 2013

Complexity asymmetry & constrained devices

Security protocols differ in how they distribute complexity between 'asserting party' and 'relying party' - and so will differ in how applicable they are to use cases where the two actors have unequal capabilities.

SAML assumes a relatively equal burden for the IdP & SP, e.g. both are assembling XML messages and may be signing those messages.

OAuth 1.0a, with its multiple tokens and client crypto requirements, likewise placed on the client a relatively high burden.

TLS can work in a symmetrical mode, one where both client & server are authenticated (and share the associated burden relatively evenly) and another where the client gets off easily (but doesnt get authenticated).

OAuth 2.0, and so OpenID Connect, was designed to move most of the complexity off the client. Being an OAuth 2.0 or OIDC client is pretty simple - assemble some HTTP messages, send them to AS via browser, keep track of some tokens, and add those tokens as headers on API calls.

So, for a constrained thing, OAuth 2.0 and OIDC make more sense than SAML (like I need to say that).

When you pair OAuth 2.0 with server-only authentication TLS (or DTLS?), you get

  1. client authentication (via OAuth 2.0)
  2. server authentication (via TLS)  
  3. data confidentiality (via TLS)
  4. data integrity (via TLS)
and, critically, keep most of the complexity off the thing and instead on the server or gateway that is likely more capable of bearing the burden.

Client-authn TLS provides all of the above security characteristics, but with a different distribution of complexity.

No comments: