O(ops), Authentication!

O(ops), Authentication!

When it comes to authentication for Restful Webservices, it seems every vendor is following another recipe. Some modes of authentication in use contradict the restful principle, some don’t. Some are secure, some are less so. We will take a tour of authentication schemes commonly found, discuss their pros and cons, and look at how to build secure, restful authentication mechanisms for your own API and various use cases.

E9612cd342dbddff6640b99db21deee7?s=128

Andreas Hucks

January 27, 2014
Tweet

Transcript

  1. O(ops), Authentication! PHPBenelux 2014

  2. Andreas Hucks @meandmymonkey • Software Architect at
 SensioLabs Deutschland •

    Symfony Trainer
  3. Authentication

  4. None
  5. Knock Knock. Client Server

  6. Who’s there? Client Server

  7. Me. Client Server

  8. kthx. Client Server

  9. HTTP is stateless.

  10. Knock Knock. BTW it's me. Client Server

  11. Not that long ago in a project not that far

    away…
  12. GET  /login?user=myname&pwd=secret DON'T TRY THIS AT HOME

  13. HTTP/1.1  200  OK   Content-­‐Type:  text/html   […]   !

    <ticket>1a2b3c4e</ticket> DON'T TRY THIS AT HOME
  14. GET  /profile?ticket=1a2b3c4e DON'T TRY THIS AT HOME

  15. Don’t roll your own.

  16. Tokens in the Query String? It happens.

  17. Basic Auth

  18. GET  /account/  HTTP/1.1   Host:  api.localhost   Authorization:  Basic  aHR0cHdhdGNoOmY=

  19. GET  /account/  HTTP/1.1   Host:  api.localhost   Authorization:  Basic  aHR0cHdhdGNoOmY=

  20. GET  /account/  HTTP/1.1   Host:  api.localhost   Authorization:  Basic  aHR0cHdhdGNoOmY=

  21. Oh, and use TLS.

  22. OAuth2

  23. Why? • Some API providing data under your control
 (GitHub,

    Facebook, Twitter…) • Third party wants access • Third party should have limited access to resource and no access to your credentials • Centralized Signons
  24. How? • Different flows to grant access • Suitable for

    different types of clients • Result is always a short-lived token that is used for authentication
  25. Who? • Facebook • Twitter • GitHub • 2567 others

    • You
  26. Timeline • RFC Expected 2010 • Published October 2012
 (RFCs

    for framework and bearer token)
  27. [snip]

  28. – RFC6749 „the method of which is beyond the scope

    of this specification"
  29. None
  30. Let’s start backwards:

  31. Resource Owner Password Credentials Grant * Certain use cases only

  32. MyApp for iDroidTM MyApi ! ! POST  /token   !

    client_id=myapp&   grant_type=password&   username=meandmymonkey&   password=supersecret&   scope=email
  33. MyApp for iDroidTM MyApi ! ! {      "access_token":"abcd",

         "token_type":"bearer",      "expires_in":3600,      "refresh_token":"1234"   }
  34. – RFC 6750 „A security token with the property that

    any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. ! Using a bearer token does not require a bearer to prove possession of cryptographic key material““
  35. Oh, and use TLS.

  36. MyApp for iDroidTM MyApi ! ! GET  /account   !

    Authorization:  Bearer   abcd
  37. Query  String               Post

     Body                   Authorization  Header   Intermezzo: Token Location
  38. Query  String               Grmpf.

      Post  Body                   Why?   Authorization  Header     Yep. Intermezzo: Token Location
  39. Auth                  

    AcmeToken             X-­‐Auth                 X-­‐AcmeToken           X-­‐Authorization   Authorization   Intermezzo: Token Location
  40. Auth                 Nope.

        AcmeToken           Nope.   X-­‐Auth               Nope.   X-­‐AcmeToken         Nope.   X-­‐Authorization     Nope.   Authorization       Yep. Intermezzo: Token Location
  41. Implementation

  42. Preconditions • Some kind of user management • Client registration

    (possibly) • Some resource you want to make accessible (duh)
  43. Don’t roll your own.

  44. oauth2-php Composer: friendsofsymfony/oauth2-php

  45. Granting the Token

  46. Protecting a Resource

  47. Authorization Grant

  48. Elements • Authorization Provider (let’s say… myapi.com) • Client -

    A third party, (let’s say… thatapp.com) • Resource owner - That’s you
  49. You MyApi ! ! GET  /authorize?   response_type=code&   client_id=thatApp&

      redirect_uri=https:// thatapp.com/auth&   state=xyz   ThatApp
  50. You MyApi ! HTTP/1.1  302   location:  https:// thatapp.com/cb?  

    code=1234&   state=xyz ThatApp
  51. Authorization

  52. You MyApi POST  /token?   ! grant_type=     authorization_code&

      code=1234&   redirect_uri=https:// thatapp.com/auth&   client_id=thatApp   ! ThatApp
  53. Granting the Token

  54. Protecting a Resource

  55. Implicit Grant

  56. You MyApi ! ! GET  /authorize?   response_type=token&   client_id=thatapp&

      redirect_uri=https:// thatapp.com/auth&   state=xyz   ThatApp
  57. You MyApi ! ! HTTP/1.1  302   location:  https:// thatapp.com/cb#

      access_token=1234&   state=xyz&   token_type=bearer&   expires_in=3600 ThatApp
  58. Implementation • PHP: Same as the previous authorization steps •

    JS: Using hello.js • bower install hello
  59. WebApp

  60. WebApp

  61. Client Credentials Grant

  62. Intermezzo:
 Shameless Plug

  63. FOSOauthServerBundle

  64. None
  65. OAuth2
 Problems & Gotchas

  66. HashMAC

  67. HMAC

  68. Simple Hash fc1de43bebbfaf6e9268fd7974100347
 884d1b4c574d31f7c17bf2f66d6f95ef hash('sha526',  'meandymonkey');

  69. Simple Hash 2d0aaf9c491869665e98a28b2d3be32b
 e9854271b4d01f2146a59c659a8d2f6f hash('sha526',  'meandYmonkey');

  70. HMAC a688746a6187b2c82d919c2a88c4fbc0   36902956ef977835e6d8267b7774f509 hash_hmac('sha256',  'meandmymonkey',  'secret');

  71. Client Key and Secret 7d5ae8a791ce21309e596274e6d69281   5d0d28493bd8bc6c84920200dd88e7d8 53335e65e0624971917d09d376dfdfc9   ae5cf625da962d314515b98753f82193

  72. MyApi ! ! GET  /profile   Authorization:   HMAC-­‐SHA256  

    Id=7d5ae8a[…],   Headers=content-­‐ type;host;date   Nonce=43hd,   Signature=a688746a[…]   Date:  Tue,  14  Aug  2013   13:32:00  GMT ThatApp
  73. Advantages • Authentication AND protection against tampering with the request

    • Can prevent replay attacks • No redirects or other extra requests • In certain circumstances can work without SSL • RESTful
  74. Now this is more difficult than you would think

  75. Canonicalizing a request • Add HTTP method • Add URI

    • Add query (needs to be canonicalized itself) • Add headers (sorted and filtered • Add nonce • Add Auth information, like Algorithm
  76. Signing it • Derive a key - derivation must be

    reproducible by the server • Create a hash of the canonicalized request • Use hash and derived key to create signature using hash_hmac();
  77. Don’t roll your own?

  78. None
  79. Hash Collisions In AWS V1 ?query=yojimbo&limit=5&offset=3 ?query=yojimbolimit=5&offset=3&

  80. … same result after normalizing: yojimbolimit5offset3 yojimbolimit5offset3

  81. Vendors • AWS V2, V3, V4 • Windows Azure API

  82. HMAC Problems

  83. X.509 Client Certificates

  84. – me „the method of which is beyond the
 scope

    of this talk"
  85. User and Credentials

  86. Wrap up: When to use what?

  87. Sharing Resources with web or mobile apps • OAuth2 Authorization

    Grant • OAuth2 HMAC extension would be nice, but • probably not there yet • ATM, same SDK problems as with pure HMAC
  88. Server to Server • Basic Auth • HMAC • OAuth2

    Client Credentials
  89. Other JS apps • OAuth2 Implicit Grant

  90. Your own JS app • OAuth2 Implicit Grant or Password

    Grant • If you are logged in for the HTML part, re-use the session (there, I said it) • Oh yes, SSL
  91. Your own Mobile App • OAuth2 Password Grant

  92. Infrastructure or Intranet Level • X.509 Client Certificates

  93. Thanks! @meandmymonkey ! http://joind.in/10285

  94. None