API Authentifizierung und Autorisierung

1.339 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Software
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.339
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
11
Aktionen
Geteilt
0
Downloads
24
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Bcrypt is crypt hash  kollisionssicher
  • Percentage Encoding
  • Percentage Encoding
  • state Optional; Unique identifier to protect against CSRF
  • state Optional; Unique identifier to protect against CSRF
  • 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

    ×