API Authentifizierung und Autorisierung

2,047 views

Published on

Folien aus dem ersten OpenDEVmeet (http://opendevmeet.at/)

Published in: Software
  • Be the first to comment

API Authentifizierung und Autorisierung

  1. 1. API Authentifizierung und Autorisierung Stefan Kienzl
  2. 2. Wer bist du? Was darfst du? Authentifizierung Autorisierung
  3. 3. Erste Überlegung Selbst implementierte Lösung Bekannte Lösung
  4. 4. Selbst implementierte Lösung Regel #1
  5. 5. Selbst implementierte Lösung Security through obscurity Security through complexity
  6. 6. Basic Authentication
  7. 7. Basic Authentication
  8. 8. Basic Authentication Client End User Server
  9. 9. Basic Authentication Client End User Server GET http://ex.com/supersave
  10. 10. Basic Authentication Client End User Server 401 Unauthorized WWW-Authenticate: Basic realm="localhost”
  11. 11. Basic Authentication Client End User Server Username Passwort
  12. 12. Basic Authentication Client End User Server Stefan Passwort1
  13. 13. Basic Authentication Client End User Server Base64Encode(Stefan:Passwort1) GET http://ex.com/supersave Authorization: Basic U3RlZmFuOlBhc3N3b3J0MQA==
  14. 14. Basic Authentication Client End User Server 200 OK 1. Base64Decode(Stefan:Passwort1) 2. Userdaten == übermittelte Daten
  15. 15. SSL / TLS Keine 100% Garantie für sichere Übertragung Minimum TLS 1.1 Oft nicht korrekt implementiert https://www.trustworthyinternet.org/ssl-pulse/
  16. 16. Basic Authentication  Leicht zu implementieren  In den meisten Libraries vorhanden  Skalierbar  Passwort kann am Server sicher gespeichert werden.  Schnell  (SSL/TLS ein wenig langsamer)
  17. 17. Basic Authentication  Passwort im Klartext übertragen  Passwort wird jedes mal übertragen  Passwort muss am Client gespeichert werden  SSL/TLS Pflicht  Man in the Middle  Keine Client identifizierung  Auch Third Party Apps benötigen Passwort  Wechsel des Passworts betrifft alle Clients  Keine Signierung der Daten  Replay Attacks  …
  18. 18. Digest Access Authentication
  19. 19. Digest Access Authentication Client End User Server GET http://ex.com/supersave
  20. 20. Digest Access Authentication Client End User Server 401 Unauthorized WWW-Authenticate: Digest realm="localhost" nonce=”stk12344”
  21. 21. Digest Access Authentication Client End User Server 401 Unauthorized WWW-Authenticate: Digest realm="localhost”, nonce=”stk12344” “Challenge”
  22. 22. Digest Access Authentication Client End User Server Username Passwort
  23. 23. Digest Access Authentication Client End User Server Stefan Passwort 1
  24. 24. Digest Access Authentication Client End User Server H1 = MD5(username:realm:passwort) H2 = MD5(Method:URI) response = MD5(H1:nonce:H2) H1 = MD5(Stefan:localhost:Passwort1) H2 = MD5(GET:/supersave) response = MD5(H1:stk12344:H2)
  25. 25. Digest Access Authentication Client End User Server GET http://ex.com/supersave Authorization: Digest username="Stefan", realm="localhost", nonce="stk12344", uri="/supersave", response="1088b263d2d86453ba75f660b38dd7cd”
  26. 26. Digest Access Authentication Client End User Server 200 OK H1 = MD5(Stefan:localhost:Passwort1) H2 = MD5(GET:/supersave) checkHash= MD5(H1:stk12344:H2) checkHash == response
  27. 27. Digest Access Authentication  opaque  Session Tracking  qop  „auth“, „auth-int“  Bestimmt ob HTTP Body in Digest inkludiert wird  cnonce count  Erhöht sich bei jedem Aufruf  Um Nonce zu erneuern  nonce  Client nonce  Replay Attacks  algorithm  stale  Bei TRUE = nonce ungültig geworden
  28. 28. Digest Access Authentication  Passwort wird nicht im Klartext übertragen  Nachrichten Signiert  SSL/TLS nicht Pflicht  Mit nonce/timestamp  keine Replay Attacks
  29. 29. Digest Access Authentication  Passwort muss am Server als Klartext gespeichert werden  Ohne SSL/TLS  Man in the Middle  Passwort muss am Client gespeichert werden  Auch Third Party Apps benötigen Passwort  Wechsel des Passworts betrifft alle Clients  Schlecht Skalierbar
  30. 30. HMAC Keyed-Hash based message authentication code
  31. 31. Keyed-Hash based message authentication code (HMAC) Client Server GET http://ex.com/supersave Authorization: hmac digest="Stefan"
  32. 32. Client Server 401 Unauthorized WWW-Authenticate: hmac, algorithm=”hmac-sha-256” Keyed-Hash based message authentication code (HMAC)
  33. 33. Client Server digest = hmac("sha256", private_key, Method + URI + UTC-TS + nonce + Parameter + Body) digest = hmac("sha256", “super_sicheres_secret”, “GET”+ “/ supersave”+ 1400781600 + 00001 + “” + “”) = 5cc52f8ff64e060ce8d4149ad0d9ef6409dfec24d6690813f6c159c5 0acae331 Keyed-Hash based message authentication code (HMAC)
  34. 34. Keyed-Hash based message authentication code (HMAC) Client Server GET http://ex.com/supersave Authorization: hmac public_key:timestamp:nonce:digest, algorithm=”hmac-sha-256”
  35. 35. Client Server 200 OK checkDigest == digest checkDigest = hmac("sha256", private_key, Method + URI + UTC-TS + nonce + Parameter + Body) Keyed-Hash based message authentication code (HMAC)
  36. 36.  Passwort wird nicht im Klartext übertragen  Nachrichten Signiert  SSL/TLS nicht Pflicht  Mit nonce/timestamp  keine Replay Attacks  HMAC sicherer als MD5 Keyed-Hash based message authentication code (HMAC)
  37. 37.  Passwort muss am Server als Klartext gespeichert werden  Ohne SSL/TLS  Man in the Middle  Passwort muss am Client gespeichert werden  Auch Third Party Apps benötigen Passwort  Wechseln der Passwört betrifft alle Clients Keyed-Hash based message authentication code (HMAC)
  38. 38. HASH Attacken Brute-Force Attacks Rainbow Tables MD5 nicht mehr empfohlen SHA-2 empfohlen Bcrypt für Passwörter Salt anhängen
  39. 39. HASH Performance Vergleich Quelle: http://msdn.microsoft.com/en-us/library/ms978415.aspx
  40. 40. OAuth OAuth Authorization Framework
  41. 41. OAuth  Authorization Framework!! Freigabe von Daten an Dritte ohne Username und Passwort freizugeben  Token basiert  Versionen  OAuth 1.0a  OAuth 2
  42. 42. OAuth User Sicht Hello stkienzl, This is a statistic about your tweets: ..... http://www.sync.com.my/version2.0/twitter_signup/index.php http://dinochiesa.net/?p=17
  43. 43. OAuth Developer Sicht Zugang zu Daten über Access Token Access Token in allen Versionen unterschiedlich Wie kommt man einen Access Token?
  44. 44. OAuth Rollen Authorization Provider Resource Server Resource Owner Client/ Customer
  45. 45. OAuth Client Registrierung  Client Identifier  Eindeutiger Name  Client Callback URL  Zusatz Informationen  zB.: Anzeigebild, Beschreibung usw. Client/ Customer Consumer/Client ID – public Consumer/Client Secret – private
  46. 46. OAuth 1.0 Access Token  Können zeitlich unbegrenzt gültig sein  Hat ein Token Secret dabei (“Private Key”) für Signatur  Muss vom Resource Owner wieder entzogen werden
  47. 47. Quelle: http://oauth.net/core/1.0/#anchor9 OAuth 1.0a Ablauf Resource Owner Data 1 2 3
  48. 48. OAuth 1.0a - Request Token Authorization Provider Resource Server Resource Owner Client
  49. 49. OAuth 1.0a - Request Token Authorization Provider Resource Server Resource Owner Client oauth_consumer_key, oauth_signature, oauth_signature_method, oauth_timestamp, oauth_nonce, oauth_callback 1
  50. 50. OAuth 1.0a - Request Token Authorization Provider Resource Server Resource Owner oauth_token, oauth_token_secret, oauth_callback_confirmed Client Überprüft Signatur 1 Request Token!!
  51. 51. OAuth 1.0a – User Authorizes Authorization Provider Resource Server Resource Owner Client oauth_token 2
  52. 52. OAuth 1.0a – User Authorizes Resource Server 2 Resource Owner Client Authorization Provider
  53. 53. OAuth 1.0a – User Authorizes Resource Server 2 Client Authorization Provider Resource Owner oauth_token, oauth_verifier Zur “Callback URL”
  54. 54. OAuth 1.0a – Request Access Token Resource Server 3 Authorization Provider Resource Owner oauth_consumer_key, oauth_token, oauth_verifier, oauth_signature_method, oauth_timestamp, oauth_nonce, oauth_callback, oauth_signature Authorization Provider Client
  55. 55. OAuth 1.0a – Request Access Token Resource Server 3 Authorization Provider Resource Owner Authorization Provider Access Token!! Client Authorization Provider oauth_token, oauth_token_secret
  56. 56. OAuth 1.0a Resource Request Authorization Provider Resource Server Resource Owner Client Customer GET /photos?file=vacation.jpg&size=original HTTP/1.1 Host: photos.example.net Authorization: OAuth realm="Photos", oauth_consumer_key="dpf43f3p2l4k3l03", oauth_token="nnch734d00sl2jdk", oauth_signature_method="HMAC-SHA1", oauth_timestamp="137131202", oauth_nonce="chapoH", oauth_signature="MdpQcU8iPSUjWoN%2FUDMsK2sui9I%3D”
  57. 57. OAuth 1.0a Signature  Signature Base String = Method +“&“+ URL +“&“+ parameter  Method (zB GET, POST ....)  URL  Ohne default Port (80 oder 443)  Ohne GET Parameter  Alles klein  HTTP Authorization Headers (außer realm), POST bzw GET Parameter  Nach Key, Value aufsteigend sortiert  Signature Key = Cosumer_Secret +“&“+ Token_Secret HMAC-SHA1(Signature Base String , Signature Key)
  58. 58. OAuth 1.0a Signature Example URL = http://photos.example.net:80/photos?file=vacation.jpg&size=original 1. GET 2. http://photos.example.net 3. file=vacation.jpg&oauth_consumer_key=dpf43f3p2l4k3l03& oauth_nonce=kllo9940pd9333jh&oauth_signature_method=HMAC-SHA1& oauth_timestamp=1191242096&oauth_token=nnch734d00sl2jdk& oauth_version=1.0&size=original GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvaca tion.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth _nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMA C- SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch 734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal http://tools.ietf.org/html/rfc3986#section-2.1
  59. 59.  Passwort muss nicht am Client gespeichert werden  Third Party Apps brauchen Passwort nie  Nachrichten Signiert  SSL/TLS nicht Pflicht  Mit nonce/timestamp  keine Replay Attacks  Mit HMAC gesichert  Passwort wechsel keine Auswirkung auf Clients OAuth 1.0a
  60. 60.  Client Credentials als Klartext gespeichert am Server/Client  Keine Authentifizierung (Native Apps)  Keine Unterstützung für Client Based App (JavaScript Apps)  Bedingt Skalierbar  Kompliziert OAuth 1.0a
  61. 61. OAuth 1.0a  OAuth 2  Zu Kompliziert  Schwer zu starten wegen Signatur  Kein Support für native Apps  Kein Support für Client-Based Apps  Schlecht Skalierbar  API (Resource Server) braucht auch alle Secrets
  62. 62. OAuth 2 OAuth Authorization Framework
  63. 63. OAuth 1.0a  OAuth 2 Keine Signatur Grant Types SSL/TLS Pflicht
  64. 64. OAuth 2 Access Token  Zeitlich begrenzt gültig  Durchschnittlich 1 Stunde  Kein Token Secret  Verschiedene Access Token Typen  Scopes – Berechtigungen hervorgehoben  Kann mit Hilfe eines Refresh Tokens erneuert werden  Refresh Token länger gültig (z.B.: 2 Wochen)
  65. 65. OAuth 2 Scopes Was darf der Client? Scopes sind definierte Berechtigungen. Client Scopes
  66. 66. OAuth 2 Grand Types  Authorization Code  Client Secret und Token kann gewahrt werden  zB: WebServer  Implicit  User-Agent-Based Application - Client Secret und Token nicht sicher  zB: Browser Apps, Third-Party mobile Apps  Resource Owner Password Credentials  Native Application - Anmeldung über User-Login Daten  zB.: Native Mobile App  Client Credentials  für Client Informationen  zB.: Statistiken oder ändern der Redirect-URL, Anzeigebild usw.  JSON Web Token  Freigabe für “Trusted Clients” ohne client_secret übermittlung Client
  67. 67. Authorization Code OAuth2
  68. 68. OAuth 2 - Authorization Code Authorization Provider Resource Server Resource Owner Client
  69. 69. OAuth 2 - Authorization Code Authorization Provider Resource Server Client Resource Owner response_type=code, client_id, redirect_url, scope, state
  70. 70. OAuth 2 - Authorization Code Resource Server Resource Owner Client Authorization Provider
  71. 71. OAuth 2 - Authorization Code Resource Server Resource Owner Client Authorization Provider callback_url, code, state Zur “Callback URL”
  72. 72. OAuth 2 - Authorization Code Authorization Provider Resource Server Client Resource Owner grant_type=authorization_code, code, redirect_url Authorization: Basic Base64(clientID:clientSECRET)
  73. 73. OAuth 2 - Authorization Code Resource Server Resource Owner Client Authorization Provider access_token token_type expires_in refresh_token
  74. 74. Implicit OAuth2
  75. 75. OAuth 2 - Implicit Authorization Provider Resource Server Resource Owner Client
  76. 76. OAuth 2 - Implicit Authorization Provider Resource Server Client Resource Owner response_type=token, client_id, redirect_url, scope, state
  77. 77. OAuth 2 - Authorization Code Resource Server Resource Owner Client Authorization Provider
  78. 78. OAuth 2 - Authorization Code Resource Server Resource Owner Client Authorization Provider callback_url#access_token=XYCtoken_ty pe=bearer& expires_in=3600& state=XYX Zur “Callback URL”
  79. 79. Resource Owner Password Credentials OAuth2
  80. 80. OAuth 2 - Resource Owner Authorization Provider Resource Server Client Resource Owner grant_type=password, username, password Authorization: Basic Base64(clientID:clientSECRET) username, password
  81. 81. OAuth 2 - Resource Owner Resource Server Resource Owner Client Authorization Provider access_token token_type expires_in refresh_token
  82. 82. Client Credentials OAuth2
  83. 83. OAuth 2 – Client Credentials Authorization Provider Resource Server Client Resource Owner grant_type=client_credentials Authorization: Basic Base64(clientID:clientSECRET)
  84. 84. OAuth 2 – Client Credentials Resource Server Resource Owner Client Authorization Provider access_token token_type expires_in
  85. 85. Refresh Token OAuth2
  86. 86. OAuth 2 - Resource Owner Authorization Provider Resource Server Client Resource Owner grant_type=refresh_token Authorization: Basic Base64(clientID:clientSECRET)
  87. 87. OAuth 2 - Resource Owner Resource Server Resource Owner Client Authorization Provider access_token token_type expires_in refresh_token
  88. 88. OAuth2 + Mac
  89. 89. OAuth 2 + MAC { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"bearer", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" } { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":“mac", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA“ "mac_key":"adijq39jdlaska9asud", "mac_algorithm":"hmac-sha-256” }
  90. 90.  Passwort muss nicht am Client gespeichert werden  Third Party Apps brauchen Passwort nie  Auch Authentifizierung  Unterstütz auch Client Based Apps  Gut Skalierbar  OAUTH 2+ MAC  Nachrichten auch signiert  Token nur begrenzt gültig  Mit Refresh Token leicht neuen anfordern  Passwort wechsel keinAauswirkung auf Clients  Weit verbreitet OAuth 2
  91. 91.  SSL/TLS Pflicht  Bei Authentifizierung muss Passwort im Klartext übertragen werden  Client Credentials als Klartext gespeichert am Server/Client  Kompliziert wenn man alle Implementierung verstehen will  Unsicherer als OAuth 1.0a OAuth 2
  92. 92. Mutual authentication
  93. 93. Mutual authentication http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication
  94. 94.  Sehr sicher  Kein Passwort Mutual authentication
  95. 95.  Kompliziert zu verwalten  Kompliziert für User  Jeder Client bzw. User brauch eigenen Private/Public Key Mutual authentication
  96. 96. Richtige Implentierung ist das wichtigste. Bestehende und getestete Libraries verweden.
  97. 97. Nachweise und Links Basic und Digest Access Authentication. http://tools.ietf.org/html/rfc2617 HMAC http://tools.ietf.org/html/rfc2104 Oauth 1.0a. http://tools.ietf.org/html/rfc5849 Oauth 2: http://tools.ietf.org/html/rfc6749 OAuth2 provider and clients: http://oauth.net/2/ OAuth1.0a und 2 provider and clients: http://oauth.net/code/ OAuth.io https://oauth.io/ OAuth.io open-source: https://github.com/oauth-io/oauthd OAuth2 Playground: https://developers.google.com/oauthplayground/ Postman (Chrome Plugin): https://chrome.google.com/webstore/detail/postman-rest- client/fdmmgilgnpjigdojojpjoooidkmcomcm
  98. 98. Bei Fragen: info@skienzl.com Twitter: stkienzl

×