Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

OAuth 2.0 und OpenId Connect

1.177 Aufrufe

Veröffentlicht am

OAuth 2.0 und OpenId Connect

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

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

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

×