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

1. API
Authentifizierung
und Autorisierung
Stefan Kienzl

2. Wer bist du?
Was darfst du?
Authentifizierung
Autorisierung

3. Erste
Überlegung
Selbst implementierte
Lösung
Bekannte Lösung

4. Selbst implementierte Lösung
Regel #1

5. Selbst implementierte
Lösung
Security through
obscurity
Security through
complexity

6. Basic
Authentication

7. Basic Authentication

8. Basic Authentication
Client
End
User
Server

9. Basic Authentication
Client
End
User
Server
GET http://ex.com/supersave

10. Basic Authentication
Client
End
User
Server
401 Unauthorized
WWW-Authenticate: Basic realm="localhost”

11. Basic Authentication
Client
End
User
Server
Username
Passwort

12. Basic Authentication
Client
End
User
Server
Stefan
Passwort1

13. Basic Authentication
Client
End
User
Server
Base64Encode(Stefan:Passwort1)
GET http://ex.com/supersave
Authorization: Basic U3RlZmFuOlBhc3N3b3J0MQA==

14. Basic Authentication
Client
End
User
Server
200 OK
1. Base64Decode(Stefan:Passwort1)
2. Userdaten == übermittelte Daten

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. 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. 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. Digest Access
Authentication

19. Digest Access Authentication
Client
End
User
Server
GET http://ex.com/supersave

20. Digest Access Authentication
Client
End
User
Server
401 Unauthorized
WWW-Authenticate: Digest realm="localhost"
nonce=”stk12344”

21. Digest Access Authentication
Client
End
User
Server
401 Unauthorized
WWW-Authenticate: Digest realm="localhost”,
nonce=”stk12344”
“Challenge”

22. Digest Access Authentication
Client
End
User
Server
Username
Passwort

23. Digest Access Authentication
Client
End
User
Server
Stefan
Passwort 1

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. 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. 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. 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. Digest Access Authentication
 Passwort wird nicht im Klartext übertragen
 Nachrichten Signiert
 SSL/TLS nicht Pflicht
 Mit nonce/timestamp  keine Replay Attacks

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. HMAC
Keyed-Hash based message
authentication code

31. Keyed-Hash based message
authentication code (HMAC)
Client
Server
GET http://ex.com/supersave
Authorization: hmac
digest="Stefan"

32. Client
Server
401 Unauthorized
WWW-Authenticate: hmac, algorithm=”hmac-sha-256”
Keyed-Hash based message
authentication code (HMAC)

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. 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. 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.  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.  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. HASH
Attacken
Brute-Force Attacks
Rainbow Tables
MD5 nicht mehr empfohlen
SHA-2 empfohlen
Bcrypt für Passwörter
Salt anhängen

39. HASH Performance
Vergleich
Quelle: http://msdn.microsoft.com/en-us/library/ms978415.aspx

40. OAuth
OAuth Authorization Framework

41. OAuth
 Authorization Framework!!
Freigabe von Daten an Dritte ohne Username und
Passwort freizugeben
 Token basiert
 Versionen
 OAuth 1.0a
 OAuth 2

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. OAuth Developer Sicht
Zugang zu Daten über Access Token
Access Token in allen Versionen unterschiedlich
Wie kommt man einen Access Token?

44. OAuth Rollen
Authorization
Provider
Resource
Server
Resource
Owner
Client/
Customer

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. 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. Quelle: http://oauth.net/core/1.0/#anchor9
OAuth 1.0a
Ablauf
Resource Owner Data
1
2
3

48. OAuth 1.0a - Request Token
Authorization
Provider
Resource
Server
Resource
Owner Client

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. 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. OAuth 1.0a – User Authorizes
Authorization
Provider
Resource
Server
Resource
Owner Client
oauth_token
2

52. OAuth 1.0a – User Authorizes
Resource
Server
2
Resource
Owner Client
Authorization
Provider

53. OAuth 1.0a – User Authorizes
Resource
Server
2
Client
Authorization
Provider
Resource
Owner
oauth_token,
oauth_verifier
Zur “Callback URL”

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. 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. 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. 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. 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.  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.  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. 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. OAuth 2
OAuth Authorization Framework

63. OAuth 1.0a  OAuth 2
Keine Signatur
Grant Types
SSL/TLS Pflicht

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. OAuth 2 Scopes
Was darf der Client?
Scopes sind definierte Berechtigungen.
Client
Scopes

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. Authorization
Code
OAuth2

68. OAuth 2 - Authorization Code
Authorization
Provider
Resource
Server
Resource
Owner Client

69. OAuth 2 - Authorization Code
Authorization
Provider
Resource
Server
Client
Resource
Owner
response_type=code,
client_id,
redirect_url,
scope,
state

70. OAuth 2 - Authorization Code
Resource
Server
Resource
Owner Client
Authorization
Provider

71. OAuth 2 - Authorization Code
Resource
Server
Resource
Owner Client
Authorization
Provider
callback_url,
code,
state
Zur “Callback URL”

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. OAuth 2 - Authorization Code
Resource
Server
Resource
Owner Client
Authorization
Provider
access_token
token_type
expires_in
refresh_token

74. Implicit
OAuth2

75. OAuth 2 - Implicit
Authorization
Provider
Resource
Server
Resource
Owner Client

76. OAuth 2 - Implicit
Authorization
Provider
Resource
Server
Client
Resource
Owner
response_type=token,
client_id,
redirect_url,
scope,
state

77. OAuth 2 - Authorization Code
Resource
Server
Resource
Owner Client
Authorization
Provider

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. Resource Owner
Password
Credentials
OAuth2

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. OAuth 2 - Resource Owner
Resource
Server
Resource
Owner Client
Authorization
Provider
access_token
token_type
expires_in
refresh_token

82. Client Credentials
OAuth2

83. OAuth 2 – Client Credentials
Authorization
Provider
Resource
Server
Client
Resource
Owner
grant_type=client_credentials
Authorization: Basic Base64(clientID:clientSECRET)

84. OAuth 2 – Client Credentials
Resource
Server
Resource
Owner Client
Authorization
Provider
access_token
token_type
expires_in

85. Refresh Token
OAuth2

86. OAuth 2 - Resource Owner
Authorization
Provider
Resource
Server
Client
Resource
Owner
grant_type=refresh_token
Authorization: Basic Base64(clientID:clientSECRET)

87. OAuth 2 - Resource Owner
Resource
Server
Resource
Owner Client
Authorization
Provider
access_token
token_type
expires_in
refresh_token

88. OAuth2 + Mac

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.  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.  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. Mutual
authentication

93. Mutual authentication
http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication

94.  Sehr sicher
 Kein Passwort
Mutual authentication

95.  Kompliziert zu verwalten
 Kompliziert für User
 Jeder Client bzw. User brauch eigenen Private/Public Key
Mutual authentication

96. Richtige Implentierung ist das wichtigste.
Bestehende und getestete Libraries verweden.

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. Bei Fragen:
info@skienzl.com
Twitter: stkienzl