API
Authentifizierung
und Autorisierung
Stefan Kienzl
Wer bist du?
Was darfst du?
Authentifizierung
Autorisierung
Erste
Überlegung
Selbst implementierte
Lösung
Bekannte Lösung
Selbst implementierte Lösung
Regel #1
Selbst implementierte
Lösung
Security through
obscurity
Security through
complexity
Basic
Authentication
Basic Authentication
Basic Authentication
Client
End
User
Server
Basic Authentication
Client
End
User
Server
GET http://ex.com/supersave
Basic Authentication
Client
End
User
Server
401 Unauthorized
WWW-Authenticate: Basic realm="localhost”
Basic Authentication
Client
End
User
Server
Username
Passwort
Basic Authentication
Client
End
User
Server
Stefan
Passwort1
Basic Authentication
Client
End
User
Server
Base64Encode(Stefan:Passwort1)
GET http://ex.com/supersave
Authorization: Basi...
Basic Authentication
Client
End
User
Server
200 OK
1. Base64Decode(Stefan:Passwort1)
2. Userdaten == übermittelte Daten
SSL / TLS
Keine 100% Garantie für sichere Übertragung
Minimum TLS 1.1
Oft nicht korrekt implementiert
https://www.trustwor...
Basic Authentication
 Leicht zu implementieren
 In den meisten Libraries vorhanden
 Skalierbar
 Passwort kann am Serve...
Basic Authentication
 Passwort im Klartext übertragen
 Passwort wird jedes mal übertragen
 Passwort muss am Client gesp...
Digest Access
Authentication
Digest Access Authentication
Client
End
User
Server
GET http://ex.com/supersave
Digest Access Authentication
Client
End
User
Server
401 Unauthorized
WWW-Authenticate: Digest realm="localhost"
nonce=”stk...
Digest Access Authentication
Client
End
User
Server
401 Unauthorized
WWW-Authenticate: Digest realm="localhost”,
nonce=”st...
Digest Access Authentication
Client
End
User
Server
Username
Passwort
Digest Access Authentication
Client
End
User
Server
Stefan
Passwort 1
Digest Access Authentication
Client
End
User
Server
H1 = MD5(username:realm:passwort)
H2 = MD5(Method:URI)
response = MD5(...
Digest Access Authentication
Client
End
User
Server
GET http://ex.com/supersave
Authorization: Digest username="Stefan", r...
Digest Access Authentication
Client
End
User
Server
200 OK
H1 = MD5(Stefan:localhost:Passwort1)
H2 = MD5(GET:/supersave)
c...
Digest Access Authentication
 opaque
 Session Tracking
 qop
 „auth“, „auth-int“
 Bestimmt ob HTTP Body in Digest inkl...
Digest Access Authentication
 Passwort wird nicht im Klartext übertragen
 Nachrichten Signiert
 SSL/TLS nicht Pflicht
...
Digest Access Authentication
 Passwort muss am Server als Klartext gespeichert werden
 Ohne SSL/TLS  Man in the Middle
...
HMAC
Keyed-Hash based message
authentication code
Keyed-Hash based message
authentication code (HMAC)
Client
Server
GET http://ex.com/supersave
Authorization: hmac
digest="...
Client
Server
401 Unauthorized
WWW-Authenticate: hmac, algorithm=”hmac-sha-256”
Keyed-Hash based message
authentication co...
Client
Server
digest = hmac("sha256", private_key, Method + URI + UTC-TS
+ nonce + Parameter + Body)
digest = hmac("sha256...
Keyed-Hash based message
authentication code (HMAC)
Client
Server
GET http://ex.com/supersave
Authorization: hmac
public_k...
Client
Server
200 OK
checkDigest == digest
checkDigest = hmac("sha256", private_key,
Method + URI + UTC-TS + nonce +
Param...
 Passwort wird nicht im Klartext übertragen
 Nachrichten Signiert
 SSL/TLS nicht Pflicht
 Mit nonce/timestamp  keine ...
 Passwort muss am Server als Klartext gespeichert werden
 Ohne SSL/TLS  Man in the Middle
 Passwort muss am Client ges...
HASH
Attacken
Brute-Force Attacks
Rainbow Tables
MD5 nicht mehr empfohlen
SHA-2 empfohlen
Bcrypt für Passwörter
Salt anhän...
HASH Performance
Vergleich
Quelle: http://msdn.microsoft.com/en-us/library/ms978415.aspx
OAuth
OAuth Authorization Framework
OAuth
 Authorization Framework!!
Freigabe von Daten an Dritte ohne Username und
Passwort freizugeben
 Token basiert
 V...
OAuth User Sicht
Hello stkienzl,
This is a statistic about your
tweets:
.....
http://www.sync.com.my/version2.0/twitter_si...
OAuth Developer Sicht
Zugang zu Daten über Access Token
Access Token in allen Versionen unterschiedlich
Wie kommt man eine...
OAuth Rollen
Authorization
Provider
Resource
Server
Resource
Owner
Client/
Customer
OAuth Client Registrierung
 Client Identifier
 Eindeutiger Name
 Client Callback URL
 Zusatz Informationen
 zB.: Anze...
OAuth 1.0 Access Token
 Können zeitlich unbegrenzt gültig sein
 Hat ein Token Secret dabei (“Private Key”) für Signatur
...
Quelle: http://oauth.net/core/1.0/#anchor9
OAuth 1.0a
Ablauf
Resource Owner Data
1
2
3
OAuth 1.0a - Request Token
Authorization
Provider
Resource
Server
Resource
Owner Client
OAuth 1.0a - Request Token
Authorization
Provider
Resource
Server
Resource
Owner Client
oauth_consumer_key,
oauth_signatur...
OAuth 1.0a - Request Token
Authorization
Provider
Resource
Server
Resource
Owner
oauth_token,
oauth_token_secret,
oauth_ca...
OAuth 1.0a – User Authorizes
Authorization
Provider
Resource
Server
Resource
Owner Client
oauth_token
2
OAuth 1.0a – User Authorizes
Resource
Server
2
Resource
Owner Client
Authorization
Provider
OAuth 1.0a – User Authorizes
Resource
Server
2
Client
Authorization
Provider
Resource
Owner
oauth_token,
oauth_verifier
Zu...
OAuth 1.0a – Request Access
Token
Resource
Server
3
Authorization
Provider
Resource
Owner
oauth_consumer_key,
oauth_token,...
OAuth 1.0a – Request Access
Token
Resource
Server
3
Authorization
Provider
Resource
Owner
Authorization
Provider
Access To...
OAuth 1.0a Resource Request
Authorization
Provider
Resource
Server
Resource
Owner
Client
Customer
GET /photos?file=vacatio...
OAuth 1.0a Signature
 Signature Base String = Method +“&“+ URL +“&“+ parameter
 Method (zB GET, POST ....)
 URL
 Ohne ...
OAuth 1.0a Signature Example
URL = http://photos.example.net:80/photos?file=vacation.jpg&size=original
1. GET
2. http://ph...
 Passwort muss nicht am Client gespeichert werden
 Third Party Apps brauchen Passwort nie
 Nachrichten Signiert
 SSL/T...
 Client Credentials als Klartext gespeichert am Server/Client
 Keine Authentifizierung (Native Apps)
 Keine Unterstützu...
OAuth 1.0a  OAuth 2
 Zu Kompliziert
 Schwer zu starten wegen Signatur
 Kein Support für native Apps
 Kein Support für...
OAuth 2
OAuth Authorization Framework
OAuth 1.0a  OAuth 2
Keine Signatur
Grant Types
SSL/TLS Pflicht
OAuth 2 Access Token
 Zeitlich begrenzt gültig
 Durchschnittlich 1 Stunde
 Kein Token Secret
 Verschiedene Access Toke...
OAuth 2 Scopes
Was darf der Client?
Scopes sind definierte Berechtigungen.
Client
Scopes
OAuth 2 Grand Types
 Authorization Code
 Client Secret und Token kann gewahrt werden
 zB: WebServer
 Implicit
 User-A...
Authorization
Code
OAuth2
OAuth 2 - Authorization Code
Authorization
Provider
Resource
Server
Resource
Owner Client
OAuth 2 - Authorization Code
Authorization
Provider
Resource
Server
Client
Resource
Owner
response_type=code,
client_id,
r...
OAuth 2 - Authorization Code
Resource
Server
Resource
Owner Client
Authorization
Provider
OAuth 2 - Authorization Code
Resource
Server
Resource
Owner Client
Authorization
Provider
callback_url,
code,
state
Zur “C...
OAuth 2 - Authorization Code
Authorization
Provider
Resource
Server
Client
Resource
Owner
grant_type=authorization_code,
c...
OAuth 2 - Authorization Code
Resource
Server
Resource
Owner Client
Authorization
Provider
access_token
token_type
expires_...
Implicit
OAuth2
OAuth 2 - Implicit
Authorization
Provider
Resource
Server
Resource
Owner Client
OAuth 2 - Implicit
Authorization
Provider
Resource
Server
Client
Resource
Owner
response_type=token,
client_id,
redirect_u...
OAuth 2 - Authorization Code
Resource
Server
Resource
Owner Client
Authorization
Provider
OAuth 2 - Authorization Code
Resource
Server
Resource
Owner Client
Authorization
Provider
callback_url#access_token=XYCtok...
Resource Owner
Password
Credentials
OAuth2
OAuth 2 - Resource Owner
Authorization
Provider
Resource
Server
Client
Resource
Owner
grant_type=password,
username,
passw...
OAuth 2 - Resource Owner
Resource
Server
Resource
Owner Client
Authorization
Provider
access_token
token_type
expires_in
r...
Client Credentials
OAuth2
OAuth 2 – Client Credentials
Authorization
Provider
Resource
Server
Client
Resource
Owner
grant_type=client_credentials
Au...
OAuth 2 – Client Credentials
Resource
Server
Resource
Owner Client
Authorization
Provider
access_token
token_type
expires_...
Refresh Token
OAuth2
OAuth 2 - Resource Owner
Authorization
Provider
Resource
Server
Client
Resource
Owner
grant_type=refresh_token
Authorizati...
OAuth 2 - Resource Owner
Resource
Server
Resource
Owner Client
Authorization
Provider
access_token
token_type
expires_in
r...
OAuth2 + Mac
OAuth 2 + MAC
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"bearer",
"expires_in":3600,
"refresh_token":"tGzv3J...
 Passwort muss nicht am Client gespeichert werden
 Third Party Apps brauchen Passwort nie
 Auch Authentifizierung
 Unt...
 SSL/TLS Pflicht
 Bei Authentifizierung muss Passwort im Klartext übertragen werden
 Client Credentials als Klartext ge...
Mutual
authentication
Mutual authentication
http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication
 Sehr sicher
 Kein Passwort
Mutual authentication
 Kompliziert zu verwalten
 Kompliziert für User
 Jeder Client bzw. User brauch eigenen Private/Public Key
Mutual authen...
Richtige Implentierung ist das wichtigste.
Bestehende und getestete Libraries verweden.
Nachweise und Links
Basic und Digest Access Authentication.
http://tools.ietf.org/html/rfc2617
HMAC
http://tools.ietf.org/...
Bei Fragen:
info@skienzl.com
Twitter: stkienzl
Nächste SlideShare
Wird geladen in …5
×

API Authentifizierung und Autorisierung

2.055 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

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

×