Das Dokument behandelt die Sicherheits-Szenarien von OAuth 2.0 und OpenID Connect (OIDC) und erläutert deren Möglichkeiten für Single Sign-On (SSO) sowie die Implementierung in ASP.NET. Es bietet eine Übersicht über die verschiedenen Abläufe, einschließlich des Authorization Code Flow und des Implicit Flow, sowie die Verwendung von JWT für die Authentifizierung und Profilübergabe. Abschließend werden Anwendungsbeispiele und Demos zur Integration mit Plattformen wie Facebook und AngularJS vorgestellt.

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
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
MOTIVATION
Page  8
Ein Benutzer - zu viele Konten
Folie 9

4. 4
Clients benötigen Zugriff
Folie 10
ÜBERBLICK ZU OAUTH 2.0
Page  11

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
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
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
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
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
Bearer-Token
Folie 24
Kein Bearer-Token
Folie 25

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
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
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
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
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
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
DEMO:
LOGIN MIT FACEBOOK
Page  51
DEMO:
LOGIN MIT IDENTITYSERVER3
Page  52

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
[mail] manfred.steyer@softwarearchitekt.at
[blog] www.softwarearchitekt.at
[web] www.campus02.at
[twitter] ManfredSteyer
Kontakt