api authentifizierung und autorisierung
DESCRIPTION
Folien aus dem ersten OpenDEVmeet (http://opendevmeet.at/)TRANSCRIPT
API Authentifizierun
g 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
ClientEnd User
Server
Basic Authentication
ClientEnd User
Server
GET http://ex.com/supersave
Basic Authentication
ClientEnd User
Server
401 UnauthorizedWWW-Authenticate: Basic realm="localhost”
Basic Authentication
ClientEnd User
Server
UsernamePasswort
Basic Authentication
ClientEnd User
Server
StefanPasswort1
Basic Authentication
ClientEnd User
Server
Base64Encode(Stefan:Passwort1)
GET http://ex.com/supersaveAuthorization: Basic
U3RlZmFuOlBhc3N3b3J0MQA==
Basic Authentication
ClientEnd 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.trustworthyinternet.org/ssl-pulse/
+
Basic Authentication
Leicht zu implementieren
In den meisten Libraries vorhanden
Skalierbar
Passwort kann am Server sicher gespeichert werden.
Schnell (SSL/TLS ein wenig langsamer)
_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
…
Digest Access Authentication
Digest Access Authentication
ClientEnd User
Server
GET http://ex.com/supersave
Digest Access Authentication
ClientEnd User
Server
401 UnauthorizedWWW-Authenticate: Digest realm="localhost"
nonce=”stk12344”
Digest Access Authentication
ClientEnd User
Server
401 UnauthorizedWWW-Authenticate: Digest realm="localhost”,
nonce=”stk12344”
“Challenge”
Digest Access Authentication
ClientEnd User
Server
UsernamePasswort
Digest Access Authentication
ClientEnd User
Server
StefanPasswort 1
Digest Access Authentication
ClientEnd 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)
Digest Access Authentication
ClientEnd User
Server
GET http://ex.com/supersaveAuthorization: Digest username="Stefan",
realm="localhost", nonce="stk12344", uri="/supersave",
response="1088b263d2d86453ba75f660b38dd7cd”
Digest Access Authentication
ClientEnd User
Server
200 OK H1 =
MD5(Stefan:localhost:Passwort1)H2 = MD5(GET:/supersave)checkHash= MD5(H1:stk12344:H2)
checkHash == response
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
+
Digest Access Authentication
Passwort wird nicht im Klartext übertragen
Nachrichten Signiert
SSL/TLS nicht Pflicht
Mit nonce/timestamp keine Replay Attacks
_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
HMACKeyed-Hash based message
authentication code
Keyed-Hash based message authentication code (HMAC)
Client
Server
GET http://ex.com/supersaveAuthorization: hmac digest="Stefan"
Client
Server
401 UnauthorizedWWW-Authenticate: hmac, algorithm=”hmac-sha-
256”
Keyed-Hash based message authentication code (HMAC)
Client
Server
digest = hmac("sha256", private_key, Method + URI + UTC-TS + nonce + Parameter + Body)
digest = hmac("sha256", “super_sicheres_secret”, “GET”+ “/ supersave”+ 1400781600 + 00001 + “” + “”) = 5cc52f8ff64e060ce8d4149ad0d9ef6409dfec24d6690813f6c159c50acae331
Keyed-Hash based message authentication code (HMAC)
Keyed-Hash based message authentication code (HMAC)
Client
Server
GET http://ex.com/supersaveAuthorization: hmac
public_key:timestamp:nonce:digest, algorithm=”hmac-sha-256”
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)
+ 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)
_ 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)
HASH
AttackenBrute-Force AttacksRainbow Tables
MD5 nicht mehr empfohlen
SHA-2 empfohlen
Bcrypt für Passwörter
Salt anhängen
HASH Performance Vergleich
Quelle: http://msdn.microsoft.com/en-us/library/ms978415.aspx
OAuthOAuth Authorization Framework
OAuth
Authorization Framework!!
Freigabe von Daten an Dritte ohne Username und Passwort freizugeben
Token basiert
Versionen OAuth 1.0a OAuth 2
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
OAuth Developer Sicht
Zugang zu Daten über Access Token
Access Token in allen Versionen unterschiedlich
Wie kommt man einen Access Token?
OAuth Rollen
Authorization
ProviderResource
Server
Resource
OwnerClient/
Customer
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
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
Quelle: http://oauth.net/core/1.0/#anchor9
OAuth 1.0a Ablauf
Resource Owner
Data
1
2
3
OAuth 1.0a - Request Token
Authorization
ProviderResource
Server
Resource
Owner Client
OAuth 1.0a - Request Token
Authorization
ProviderResource
Server
Resource
Owner Client
oauth_consumer_key,oauth_signature,oauth_signature_method,oauth_timestamp,oauth_nonce,oauth_callback
1
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!!
OAuth 1.0a – User Authorizes
Authorization
ProviderResource
Server
Resource
Owner Client
oauth_token
2
OAuth 1.0a – User Authorizes
Resource
Server
2Resource
Owner Client
Authorization Provider
OAuth 1.0a – User Authorizes
Resource
Server
2
Client
Authorization Provider
Resource
Owner
oauth_token,oauth_verifier
Zur “Callback URL”
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
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
OAuth 1.0a Resource Request
Authorization
ProviderResource
Server
Resource
OwnerClient
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”
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)
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=originalGET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal
http://tools.ietf.org/html/rfc3986#section-2.1
+ 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
_ 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
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
OAuth 2OAuth 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 Token Typen
Scopes – Berechtigungen hervorgehoben
Kann mit Hilfe eines Refresh Tokens erneuert werden Refresh Token länger gültig (z.B.: 2 Wochen)
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-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
Authorization Code
OAuth2
OAuth 2 - Authorization Code
Authorization
ProviderResource
Server
Resource
Owner Client
OAuth 2 - Authorization Code
Authorization
ProviderResource
Server
ClientResource
Owner
response_type=code, client_id, redirect_url,scope,state
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 “Callback URL”
OAuth 2 - Authorization Code
Authorization
ProviderResource
Server
ClientResource
Owner
grant_type=authorization_code, code, redirect_url
Authorization: Basic Base64(clientID:clientSECRET)
OAuth 2 - Authorization Code
Resource
Server
Resource
Owner Client
Authorization Provider
access_token token_typeexpires_in refresh_token
ImplicitOAuth2
OAuth 2 - Implicit
Authorization
ProviderResource
Server
Resource
Owner Client
OAuth 2 - Implicit
Authorization
ProviderResource
Server
ClientResource
Owner
response_type=token, client_id, redirect_url,scope,state
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=XYCtoken_type=bearer&
expires_in=3600& state=XYX
Zur “Callback URL”
Resource Owner
Password Credentials
OAuth2
OAuth 2 - Resource Owner
Authorization
ProviderResource
Server
ClientResource
Owner
grant_type=password, username, password
Authorization: Basic Base64(clientID:clientSECRET)
username, password
OAuth 2 - Resource Owner
Resource
Server
Resource
Owner Client
Authorization Provider
access_token token_typeexpires_in refresh_token
Client Credentials
OAuth2
OAuth 2 – Client Credentials
Authorization
ProviderResource
Server
ClientResource
Owner
grant_type=client_credentials
Authorization: Basic Base64(clientID:clientSECRET)
OAuth 2 – Client Credentials
Resource
Server
Resource
Owner Client
Authorization Provider
access_token token_typeexpires_in
Refresh TokenOAuth2
OAuth 2 - Resource Owner
Authorization
ProviderResource
Server
ClientResource
Owner
grant_type=refresh_token
Authorization: Basic Base64(clientID:clientSECRET)
OAuth 2 - Resource Owner
Resource
Server
Resource
Owner Client
Authorization Provider
access_token token_typeexpires_in refresh_token
OAuth2 + Mac
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” }
+ 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
_ 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
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 authentication
Richtige Implentierung ist das wichtigste.
Bestehende und getestete Libraries verweden.
Nachweise und Links
Basic und Digest Access Authentication.http://tools.ietf.org/html/rfc2617
HMAChttp://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.iohttps://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