API Authentifizierung und Autorisierung

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



ClientEnd User

Server


ClientEnd User

Server

GET http://ex.com/supersave


ClientEnd User

Server

401 UnauthorizedWWW-Authenticate: Basic realm="localhost”


ClientEnd User

Server

UsernamePasswort


ClientEnd User

Server

StefanPasswort1


ClientEnd User

Server

Base64Encode(Stefan:Passwort1)

GET http://ex.com/supersaveAuthorization: Basic

U3RlZmFuOlBhc3N3b3J0MQA==


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/

+


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


ClientEnd User

Server

GET http://ex.com/supersave


ClientEnd User

Server

401 UnauthorizedWWW-Authenticate: Digest realm="localhost"

nonce=”stk12344”


ClientEnd User

Server

401 UnauthorizedWWW-Authenticate: Digest realm="localhost”,

nonce=”stk12344”

“Challenge”


ClientEnd User

Server

UsernamePasswort


ClientEnd User

Server

StefanPasswort 1


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)


ClientEnd User

Server

GET http://ex.com/supersaveAuthorization: Digest username="Stefan",

realm="localhost", nonce="stk12344", uri="/supersave",

response="1088b263d2d86453ba75f660b38dd7cd”


ClientEnd User

Server

200 OK H1 =

MD5(Stefan:localhost:Passwort1)H2 = MD5(GET:/supersave)checkHash= MD5(H1:stk12344:H2)

checkHash == response


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

+


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



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”


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



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)


+ Passwort wird nicht im Klartext übertragen




HMAC sicherer als MD5


_ Passwort muss am Server als Klartext gespeichert werden

Ohne SSL/TLS Man in the Middle



Wechseln der Passwört betrifft alle Clients


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


Authorization

ProviderResource

Server

Resource

Owner Client

oauth_consumer_key,oauth_signature,oauth_signature_method,oauth_timestamp,oauth_nonce,oauth_callback

1


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


Resource

Server

2Resource

Owner Client



Resource

Server

2

Client


Resource

Owner

oauth_token,oauth_verifier

Zur “Callback URL”

OAuth 1.0a – Request Access Token

Resource

Server

3


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


Resource

Owner


Access Token!!

Client


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




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


Authorization

ProviderResource

Server

ClientResource

Owner

response_type=code, client_id, redirect_url,scope,state


Resource

Server

Resource

Owner Client



Resource

Server

Resource

Owner Client


callback_url,code,state



Authorization

ProviderResource

Server

ClientResource

Owner

grant_type=authorization_code, code, redirect_url

Authorization: Basic Base64(clientID:clientSECRET)


Resource

Server

Resource

Owner Client


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


Resource

Server

Resource

Owner Client



Resource

Server

Resource

Owner Client


callback_url#access_token=XYCtoken_type=bearer&

expires_in=3600& state=XYX


Resource Owner

Password Credentials

OAuth2

OAuth 2 - Resource Owner

Authorization

ProviderResource

Server

ClientResource

Owner

grant_type=password, username, password


username, password


Resource

Server

Resource

Owner Client



Client Credentials

OAuth2

OAuth 2 – Client Credentials

Authorization

ProviderResource

Server

ClientResource

Owner

grant_type=client_credentials


OAuth 2 – Client Credentials

Resource

Server

Resource

Owner Client


access_token token_typeexpires_in

Refresh TokenOAuth2


Authorization

ProviderResource

Server

ClientResource

Owner

grant_type=refresh_token



Resource

Server

Resource

Owner Client



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


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

+ Sehr sicher

Kein Passwort


_ Kompliziert zu verwalten

Kompliziert für User

Jeder Client bzw. User brauch eigenen Private/Public Key


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

Bei Fragen:

[email protected]

Twitter: stkienzl

API Authentifizierung und Autorisierung

Software

client server digest

hmac digest

digest realm

body digest

digest username

passwort h2

digest checkdigest

hmac keyedhash