Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DWX2021 - Hier kommst Du ned rein. ASP.NET Core...

DWX2021 - Hier kommst Du ned rein. ASP.NET Core APIs und Angular Security mit Azure

Schwachstellen in Software sind (leider) allgegenwärtig und die Zahl der Angriffe steigt kontinuierlich an. Daher ist es unabdingbar, dass die Software richtig geschützt wird. Das Thema Security scheint aber vielen Entwicklern viel zu mühsam und komplex zu sein. In unseren Projekten stellen wir immer wieder fest, dass das Thema Security nur mangelhaft oder gar nicht berücksichtigt wurde. Diese Session zeigt auf, wie Authentication und Authorization in einer Angular Applikation mit einem ASP.NET Core Backend implementiert werden kann. Wir zeigen, was alles beachtet werden muss und was es mit Standards wie OAuth und OpenID Connect so auf sich hat.

Manuel Meyer

June 30, 2021
Tweet

More Decks by Manuel Meyer

Other Decks in Technology

Transcript

  1. thomasgassmann.net manuelmeyer.net @gassmannT @manumeyer1 Du kommst hier ned rein! ASP.NET

    Core APIs und Angular Security mit Azure Manuel Meyer, Thomas Gassmann Developer Week 2021
  2. Manuel Meyer helps customers: • to kick-start the Azure journey.

    • to architect, implement and optimize their Azure Solutions www.manuelmeyer.net www.azurezurichusergroup.com @manumeyer1
  3. Thomas Gassmann helps customers: • to architect and implement their

    business applications • with the migration of large application www.thomasgassmann.net @gassmannT
  4. Agenda ▪ Wieso diese Session? ▪ OAuth 2.0 & OpenID

    Connect ▪ Zielarchitektur ▪ Demo
  5. OAuth? Du Depp hast es genau falsch rum gemacht und

    NIX verstanden! Der nächste Blog Post: GAR NIX VERSTANDEN!!!
  6. OAuth? OAuth 2.0 OIDC Resource Server Token SAML Delegation Claims

    Implicit Flow Code Flow Code Challenge PKCE Identity Server Resource
  7. OAuth 2.0 Herausforderungen ▪ Die Spezifikation ist unvollständig bzw. zu

    offen ▪ Es gibt viele unterschiedliche Implementierungen ▪ Viele neue Begriffe und Konzepte ▪ Die Authorization Flows sind komplex ▪ Es gibt 1 Million verschiedene Meinungen zum Thema.
  8. OAuth 2.0 ▪ IETF ▪ RFC 6749 ▪ 75 Seiten

    ▪ Von 2012 https://datatracker.ietf.org/doc/html/rfc6749
  9. Probleme? ▪ Dein Passwort ist geheim! ▪ Mit dem Passwort

    kann die Client-App auf ALLES zugreifen ▪ Der Resource Owner gibt die Kontrolle aus der Hand OAuth löst diese Probleme. Aber: ▪ OAuth macht NUR die Authorization ▪ OAuth wurde erfunden für die Delegated Authorization.
  10. OAuth Scopes ▪ Definieren auf was ein Resource Owner Zugriff

    zulassen kann ▪ Format: <resource server> & <scope> ▪ -> Der Resource Owner (Mensch) muss die Scopes verstehen DwxAPI api://dwxapi/speakers.read api://dwxapi/speakers.write api://dwxapi/sessions.read api://dwxapi/sessions.write api://dwxapi/rooms.read api://dwxapi/rooms.write Gmail https://www.googleapis.com/auth/gmail.compose https://www.googleapis.com/auth/gmail.send https://www.googleapis.com/auth/gmail.settings
  11. OAuth 2.0 Flows? ▪ Client Credential Flow ▪ Authorization Code

    Flow ▪ Authorization Code Flow with PKCE ▪ Device Code Flow ▪ Refresh Token Flow ▪ Resource Owner Password Credential Flow ROPC ▪ Implicit Flow.
  12. OAuth 2.0 Flows? ▪ Client Credential Flow -> Machine-to-Machine, no

    user ▪ Authorization Code Flow ▪ Authorization Code Flow with PKCE ▪ Device Code Flow -> No keyboard, no browser (Azure CLI, Apple TV) ▪ (Refresh Token Flow) -> included in the Authorization Code Flows ▪ Resource Owner Password Credential Flow ROPC ▪ Implicit Flow Legacy Flows (Do NOT use) Special Flows
  13. OAuth 2.0 Flows? ▪ Client Credential Flow -> Machine-to-Machine, no

    user ▪ (Authorization Code Flow) ▪ Authorization Code Flow with PKCE ▪ Device Code Flow -> No keyboard, no browser (Azure CLI, Apple TV) ▪ (Refresh Token Flow) -> included in the Authorization Code Flows ▪ Resource Owner Password Credential Flow ROPC ▪ Implicit Flow Legacy Flows (Do NOT use) Special Flows
  14. OAuth 2.0 Authorization Code Flow Resource Resource Owner Client (Application)

    Darf ich die Daten von Manu lesen (Scopes[])? Authorization Server Klaro («auth code») Access Token Request («auth code» & «secret») Zugriff (Access Token) Access Token Daten 1 2 3
  15. OpenID Connect (OIDC) Ist ein Authentifizierungsstandard, der auf OAuth aufbaut.

    OIDC ergänzt die OAuth Spezifikation und ist spezifischer. Oauth 2.0 (Authz) ▪ ID Token (Login & Profile) ▪ Token Format: JWT (say «JOT») ▪ Standard Scopes (openid, profile, email, address) ▪ Standard Claims (e.g. family_name). OIDC (Authn) ▪ Access/Refresh Tokens ▪ Token Format: any ▪ Scopes: any ▪ Claims: any
  16. OAuth 2.0 Authorization Code Flow Resource Resource Owner Client (Application)

    Authorization Server Klaro («auth code», «ID Token») Access Token Request («auth code» & «secret») Zugriff (Access Token) Access Token Daten Darf ich die Daten von Manu lesen («scopes[]») 1 3 4 2 Login & consent
  17. Schwachstellen in Oauth 2.0 Resource Resource Owner Client (Application) Authorization

    Server Klaro («auth code», «ID Token») Access Token Request («auth code» & «secret») Zugriff (Access Token) Access Token Daten Darf ich die Daten von Manu lesen («scopes[]») 1 3 4 2 Login & consent
  18. Public Client vs. Confidential Client Public Client ▪ Kann ein

    Secret NICHT sicher speichern ▪ Browser Apps (SPAs), Mobile Apps, Desktop Apps Confidential Client ▪ Kann ein Secret sicher speichern ▪ Klassische Web Apps mit Server Side Rendering (ASP.NET, etc.) Lösung: Implicit Flow (legacy) Authorization Code flow with PKCE.
  19. OAuth 2.0 Authorization Code Flow Resource Resource Owner Client (Application)

    Authorization Server Klaro («auth code») Access Token Request («auth code» & «secret») Zugriff (Access Token) Access Token Daten Darf ich die Daten von Manu lesen («scopes[]») 1 3 4 2 Login & consent
  20. Implicit Flow (Legacy = Nicht verwenden!) Resource Resource Owner Client

    (Application) Darf ich die Daten von Manu lesen? Authorization Server Klaro («access token») Zugriff (Access Token) Daten 1 3 2 Login & consent
  21. PKCE (say “Pixie”) Proof Key for Code Exchange (Alternative zum

    Implicit Flow) 1. Der Client generiert ein «Secret» ad-hoc und schickt es als Hashwert (code_challenge) an den Authorization Server 2. Der Authorization Server speichert diesen Hashwert 3. Wenn der Client einen Access Token anfordert muss er den Hashwert mitschicken 4. Der Authorization Server vergleicht den Hashwert mit dem gespeicherten und schickt bei Übereinstimmung ein Access Token zurück. PKCE stellt sicher, dass der client, welcher den Access Token bestellt hat, der gleiche Client ist welcher die Authentifizierung gemacht hat!
  22. Auth Code with PKCE Resource Resource Owner Client (Application) Darf

    ich die Daten von Manu lesen? Authorization Server Klaro («auth code») Access Token Request («auth code» & «secret») Zugriff (Access Token) Access Token Daten 1 2 4 Login & consent 3 +code_challenge +code_challenge
  23. JWT Tokens ▪ OIDC - ID Token: Who is the

    user? ▪ OAuth 2.0 - Access Token: The user is allowed to access scopes a,b,c on resource server «DWXApi». ▪ OAuth 2.0: Refresh Token: Can be used to renew an Access Token ▪ Tokens sind kryptografisch signiert aber nicht verschlüsselt. Tooling: https://jwt.ms.
  24. Angular ▪ Es gibt viele npm Pakete für Angular. Z.B.

    ▪ @azure/msal-angular (Microsoft) ▪ angular-oauth2-oidc (Manfred Steyer) ▪ angular-auth-oidc-client (Damien Bowden & Fabian Gosebrink)
  25. Zusammenfassung ▪ OAuth 2.0 und OpenID kommen im Doppelpack ▪

    Authorization Code with PKCE ist der empfohlene Flow für Web Apps ▪ Die Implementierungsdetails übernehmen die Libraries ▪ Trotzdem müssen die Konzepte verstanden werden.