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

1.428 Aufrufe

Veröffentlicht am

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

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

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.428
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
11
Aktionen
Geteilt
0
Downloads
26
Kommentare
0
Gefällt mir
2
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

    ×