OAuth 2.0 und OpenId Connect

1.082 Aufrufe

Veröffentlicht am

OAuth 2.0 und OpenId Connect

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

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.082
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
10
Aktionen
Geteilt
0
Downloads
14
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

OAuth 2.0 und OpenId Connect

  1. 1. 1 Zeitgemäße Sicherheitsszenarien mit OAuth 2.0 und OpenId Connect Manfred Steyer | www.IT-Visions.de | FH CAMPUS 02 ManfredSteyer Side-Projects Page  2 www.software-engineering-leadership.de
  2. 2. 2 Ziele Möglichkeiten bezüglich SSO und Delegation mit OAuth 2.0 und OpenId Connect (OIDC) kennen lernen Möglichkeiten zur Umsetzung in ASP.NET kennen lernen Folie 6 Inhalt Motivation Überblick zu OAuth 2.0 SSO mit OAuth 2.0 und OIDC Überblick zu OWIN und Katana Demo: Login mit Facebook Demo: Login mit IdentityServer3 Demo: OpenId Connect mit AngularJS Folie 7
  3. 3. 3 MOTIVATION Page  8 Ein Benutzer - zu viele Konten Folie 9
  4. 4. 4 Clients benötigen Zugriff Folie 10 ÜBERBLICK ZU OAUTH 2.0 Page  11
  5. 5. 5 Was ist OAuth ? Ursprünglich Entwickelt von Twitter und Ma.gnolia Protokoll zum Delegieren von (eingeschränkten) Rechten Mittlerweile verwendet von Google, Facebook, Flickr, Microsoft, Salesforce.com oder Yahoo! Verschiedene Flows Folie 12 Rollen (vereinfacht) Folie 13 Client Authorization-Server Ressource-Server User Registriert mit client_id, client_secret, redirect_uri Registriert mit Credentials
  6. 6. 6 Prinzipieller Ablauf Folie 14 Client Authorization-Server Ressource-Server 1. Umleitung 2. Umleitung 3. Token Details legt Flow fest Ein zentrales Benutzerkonto Nut Auth-Svr. kennt Passwort Token-Format OAuth 2 schreibt kein Token-Format vor Ressource Server muss Token validieren können Möglichkeiten zum Validieren  Bei Auth-Server nachfragen  Signatur prüfen  Token entschlüsseln Folie 15
  7. 7. 7 Token-Formate GUID (Referenz-Token) Eigenes Tokenformat  Verschlüsselung und/oder Signatur durch Auth-Server JWT: JSON Web Token  JSON-Dokument beschreibt Claims  Kann signiert und/oder verschlüsselt sein  Header gibt Auskunft über verwendete Krypto-Algorithmen Folie 16 AUTHORIZATION CODE FLOW Page  19
  8. 8. 8 Authorization Code Flow Am meisten Sicherheitsmerkmale Klassische Web-Anwendungen Native Anwendungen  Öffnen ein Fenster mit Browser-Control Folie 20 Authorization Code Flow Folie 21 Client Authorization-Server 1. Umleitung 2. Umleitung ?response_type=code &client_id=… &scope=… &state=… &redirect_uri=… ?code=4711 &state=… Code User Client Scope 4711 Max 0815 voucher
  9. 9. 9 Authorization Code Flow Folie 22 Client Authorization-Server 3. Service-Zugriff 4. Antwort ?response_type= authorization_code &client_id=… &client_secret=… &code=4711 &redirect_uri=… { access_token="…", refresh_token="…", expires_in=…, … } Code User Client Scope 4711 Max 0815 voucher Authorization Code Flow Folie 23 Client Ressource-Server 3. Token Authorization: Bearer abcdef…
  10. 10. 10 Bearer-Token Folie 24 Kein Bearer-Token Folie 25
  11. 11. 11 IMPLICIT FLOW Page  26 Implicit Flow Weniger Sicherheitsmerkmale als Authorization Code Flow Gedacht für Clients, die ein Secret nicht sicher verwahren können JavaScript-Clients Single Page Applications Folie 27
  12. 12. 12 Implicit Flow Folie 28 Client Authorization-Server 1. Umleitung 2. Umleitung ?response_type=token &client_id=… &scope=… &state=… &redirect_uri=… #access_token=… &state=… &expires_in=… Eigenschaften Keine Authentifizierung des Clients ClientId muss zur registrierten RedirectUri passen Token am Client Kein Refresh-Token Folie 29
  13. 13. 13 WEITERE FLOWS Page  30 Weitere Flows Resource Owner Password Credentials Flow  Benutzer vertraut Client seine Credentials an  Client tauscht diese Credentials gegen Token ein Client Credentials Grant  Client "in eigener Mission"  Client tauscht eigene Credentials gegen Token ein Extension Grants Folie 31
  14. 14. 14 SSO MIT OAUTH 2.0 UND OPENID CONNECT Page  36 SSO mit OAuth Folie 37 Client Authorization-Server Ressource- Server 3. /user/profile + Token 1. Token anfordern { "user_name": "susi", "email": "susi@sorglos.at", … } 2. Token &scope=profile Nicht durch OAuth 2.0 definiert
  15. 15. 15 OpenId Connect (OIDC) Erweiterung zu OAuth 2.0 Standardisiert User-Profil-Endpunkt Standardisiert Übermittlung von Profil-Infos Token beinhaltet Audience Client erhält auch ID-Token  JWT-Token mit Infos zum Benutzer + Audience  JWT-Token kann vom Aussteller signiert sein Folie 42 OIDC Folie 43 Authorization-Server Client 1 Service 1 Access-Token ID-Token /voucher + Access-Token
  16. 16. 16 OWIN UND KATANA Page  45 Hosting mit OWIN Folie 46 Server Web-Framework Web-Application Middleware1 Middleware2 Middleware… Middlewaren Anfrage Antwort Host-Prozess HTTP
  17. 17. 17 DEMO: LOGIN MIT FACEBOOK Page  51 DEMO: LOGIN MIT IDENTITYSERVER3 Page  52
  18. 18. 18 DEMO: OAUTH 2 MIT ANGULARJS Page  53 Fazit  OAuth 2.0 zum Delegieren von Rechten  Authorization Code Flow: Klassische Web-Anwendungen  Authorization Code Flow: Desktop-Anwendungen (Browser-Control)  Implicit Flow: Single Page Applications  SSO: Recht zum Lesen von Profil delegieren  OpenID Connect: Authentifizierung mit OAuth 2.0  OpenID Connect: JWT --> Zusätzliche Sicherheitsmerkmale  Katana-Middleware für Login with Facebook & Co.  Katana-Middleware für OAuth 2.0/ Fork für OIDC Folie 58
  19. 19. 19 [mail] manfred.steyer@softwarearchitekt.at [blog] www.softwarearchitekt.at [web] www.campus02.at [twitter] ManfredSteyer Kontakt

×