Login und Access-Control für SPA

Login und Access-Control für SPA

Session from w-jax 2017 in Munich

15934fa2aa7b2ce21f091e9b7cffa856?s=128

Manfred Steyer

November 08, 2017
Tweet

Transcript

  1. Muster für Login- und Access Control in SPA Manfred Steyer

    SOFTWAREarchitekt.at ManfredSteyer
  2. Über mich … • Manfred Steyer • SOFTWAREarchitekt.at • Trainer

    & Consultant • Fokus: Angular • Google Developer Expert (GDE) Page ▪ 3 Manfred Steyer
  3. Inhalt • Motivation • OAuth 2 • OpenId Connect •

    Token Refresh • Single Sign out • DEMO mit Angular
  4. Zugriff auf App und Backend

  5. HTTP Basic und Co? Username+Password Username+Password ? ?

  6. Probleme Sensible Daten immer übertragen? Delegation an andere Server? Jeder

    Server prüft Credentials? Single Sign on?
  7. Cookies? Username + Password Cookie Cookie ? ?

  8. Probleme XSRF Delegation an andere Server? Cross Origin? Single Sign

    on?
  9. None
  10. Token? Username + Password Token Token Token' Token

  11. Probleme Anbindung existierender Identity Lösungen? Lose Kopplung zu Identity Lösung?

    Single Sign On? Client sieht Passwort
  12. Rollen Folie▪ 13 Client Authorization-Server Resource-Server

  13. Prinzipieller Ablauf Folie▪ 14 Client Authorization-Server Resource-Server 1. Umleitung 2.

    Umleitung mit Access-Token 3. Access-Token Ein zentrales Benutzerkonto Nur Auth-Svr. kennt Passwort Auth. von Client entkoppelt Flexibilität durch Token SPA: Kein Cookie: Kein CSRF
  14. OAuth 2

  15. 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▪ 16
  16. Implicit Flow für SPA Folie▪ 17 Client Authorization-Server Resource-Server 1.

    Umleitung 2. Umleitung mit Access-Token 3. Access-Token
  17. Token (typische Inhalte) • Informationen über Benutzer (Claims) • Rechte,

    die der Client wahrnehmen darf • Aussteller • Audience (für wen wurde Token ausgestellt) • Gültigkeitsdatum • Signatur des Ausstellers Folie▪ 18
  18. Token-Format • OAuth 2 schreibt kein Token-Format vor • Ressource

    Server muss Token validieren können Folie▪ 19
  19. Token-Formate (Auswahl) • GUID (Referenz-Token) • Eigenes Tokenformat • JWT:

    JSON Web Token • JSON-Dokument beschreibt Claims • Kann signiert und/oder verschlüsselt sein Folie▪ 20
  20. SSO und OpenID Connect Page ▪ 23

  21. SSO mit OAuth Folie▪ 24 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
  22. OpenId Connect (OIDC) • Erweiterung zu OAuth 2.0 • Standardisiert

    User-Profil-Endpunkt (Service mit Daten zum Benutzer) • Client erhält auch ID-Token • JWT-Token mit Infos zum Benutzer + Audience • JWT-Token kann vom Aussteller signiert sein Folie▪ 25
  23. Implicit Flow mit OIDC Folie▪ 26 Client Authorization-Server Resource-Server 1.

    Umleitung 2. Umleitung mit Access-Token und Id-Token 3. Access-Token
  24. Demo • Angular • angular-oauth2-oidc • OIDC Certified • Identity

    Server in Cloud
  25. DEMO

  26. Refresh Page ▪ 29

  27. Warum Refresh? Kurzlebige Token erhöhen Sicherheit Benutzer möchte sich aber

    nicht ständig manuell anmelden
  28. Refresh Token (1) Folie▪ 31 Client Authorization-Server Resource-Server 1. Umleitung

    2. Umleitung mit Access-Token und Id-Token und Refresh-Token
  29. Refresh Token (2) Folie▪ 32 Client Authorization-Server Resource-Server 3. Refresh-Token

    4. Umleitung mit Access-Token und Id-Token und neuem Refresh-Token
  30. Kein Refresh-Token bei Implicit Flow Leider oder zum Glück?

  31. Refresh dank Cookie Folie▪ 34 Client Authorization-Server Resource-Server 1. Umleitung

    2. Umleitung mit Access-Token und Id-Token
  32. Silent Refresh Folie▪ 35 Client Authorization-Server Resource-Server 1. Umleitung in

    verstecktem iFrame 2. Umleitung mit Access-Token und Id-Token
  33. DEMO

  34. Single Sign out

  35. Single Sign out Folie▪ 38 Client B Authorization-Server Resource-Server 1.

    Abmelden 2. Abmelden Client A
  36. Kanal zum Client offenhalten? • Websockets • Server Send Events

    • Hidden IFrame • OIDC Session Management
  37. DEMO Page ▪ 40

  38. Fazit Token: Flexibilität und Cross Origin OAuth 2: Autorisierung OpenId

    Connect: Authentifizierung Implicit Flow Silent Refresh Single Sign out
  39. Kontakt und Downloads [mail] manfred.steyer@SOFTWAREarchitekt.at [blog] SOFTWAREarchitekt.at [twitter] ManfredSteyer