Dieses Kapitel bietet eine detaillierte Beschreibung der Prozessflüsse welche für eine Anmeldung mittels ID Austria an einem Service-Providers durchgeführt werden. Die Anmeldung kann entweder in in einer mobilen Applikation oder web-basierten Applikation des Service Providers durchgeführt werden. Für die technische Kommunikation zwischen Service-Provider und ID Austria System stehen die Authentifizierungsprotokolle SAML2 und OIDC zur Verfügung.

Anmeldung mit SAML2

Prozessfluss für SAML2 in Web Browser Anwendungen

Dieser Prozessfluss beschreibt eine SAML2 Authentifizierung eines Benutzers wobei die Interaktion mit dem Benutzer über dessen Web Browser erfolgt. Abbildung 1 bietet eine Darstellung des Prozessflusses aus Sicht des Benutzers im Web Browser.

1. Der Benutzer möchte mittels Web-Browser auf eine geschützte Ressource in der Online-Applikation eines Service Providers (SP) zugreifen.
2. Der Service Provider erkennt, dass es sich um einen nicht-authentifizierten Benutzer handelt und antwortet dem Browser mit einem SAML2 Authentifizierungsrequest und einer Weiterleitung zum Identity Provider (IdP) des ID Austria Systems.
3. Der Browser sendet einen Authentifizierungsrequest an den IdP, worauf dieser mit einer HTML Seite zur Auswahl der zur Verfügung stehenden Authentifizierungsmethoden, per VDA (ID Austria), oder optional eine Anmeldung per EU-Login (eIDAS), antwortet. Der Benutzer entscheidet sich an dieser Stelle für eine der Authentifizierungsvarianten. Die nochfolgenden Prozessschritte basieren auf der Annahme dass der Benutzer VDA (ID Austria) gewählt hat.
4. Nach Auswahl der Authentifizierungsmethode schickt der IdP ein Security-Layer 2.0 Kommando an den VDA, um einen ID Austria spezifischen Identifikations- und Authentifizierungsprozess am VDA zu starten.
5. Im Zuge des Identifikations- und Authentifizierung wird die Telefonnummer und das Signaturpasswort des Benutzers abgefragt. Die Abfrage der Telefonnummer entfällt falls der Benutzer Identifikation und Authentifizierung vollständig in der mobilen App durchführen kann, z.B. bei Services auf mobilen Geräten.
6. Danach kann die Authentifizierung mit 3 Varianten fortgesetzt werden:
   • Authentifizierung über initialisierte ID Austria App: Der VDA sendet eine Push-Notification an die ID Austria App des Benutzers wodurch diese am mobilen Gerät geöffnet wird. Anschließend kann die ID Austria App zur Eingabe des zweiten Faktors für die Authentifizierung zu verwenden. Hierfür stehen aktuell Fingerprint und Gesichtserkennung zur Authentifizierung zur Verfügung.
   • Authentifizierung in initialisierte ID Austria App: Der Benutzer befindet sich bereits in der ID Austria App und wird direkt zur Eingabe des zweiten Faktors aufgefordert.
   • Authentifizierung ohne ID Austria App: Der VDA sendet einen SMS-TAN an das Mobiltelefon des Benutzers, der anschließend in der Eingabemaske im Web-Browser eingegeben werden muss. Alternativ kann ein QR Code mit einer VDA spezifischen App gescannt werden, um einen App-TAN zu übermitteln.
7. Nach einer erfolgreichen Authentifizierung wird eine qualifizierte Signatur, welche die Benutzerauthentifizierung für das ID Austria System darstellt, erzeugt. Die qualifizierte Signatur und weitere Basisdaten zum Benutzer werden anschließend an den IdP zurückgeliefert, welcher die weitere Kommunikation mit dem ID Austria Backend übernimmt, um die Personenbindung anzufordern.
8. Der IdP antwortet dem Browser mit einer SAML2 Authentifizierungsresponse, welche die SAML2-Assertion und somit die Identifikationsdaten des Benutzers beinhaltet, und der Aufforderung zur Weiterleitung an den Service-Provider.
9. Der Browser übermittelt die SAML2 Authentifizierungsresponse an die Applikation des SP. Nach erfolgreicher Validierung der SAML2 Authentifizierungsresponse durch den SP ist der Benutzer angemeldet.

Anmeldung mit OpenID Connect

Die Prozessflüsse einer Anmeldung mit OpenId Connect (OIDC) unterscheidet sich abhängig vom gewählten Response-Type und dem damit verbundenen Authentication Flow. Vom ID Austria System werden wird jedoch nur der Response-Type: code und somit der Authorization Code Flow, entsprechend der OIDC Spezifikation unterstützt. Die nachfolgenden Kapitel geben einen allgemeinen Überblick zum Authorization Code Flow im ID Austria sowie mögliche Szenarien für den Einsatz von OpenID Connect zur Authentifizierung in Apps auf mobilen Geräten.

Authorization Code Flow in OIDC

Der Authorization Code Flow eignet sich für Web-Browser basierte Anwendungen sowie für native (mobile oder Desktop-) Anwendungen welche über eine Anbindung an ein Backend System des Service Providers verfügen. Abbildung 2 bietet eine Darstellung des Prozessflusses des Authorization Code Flow.

1. Der Benutzer möchte mittels eines von ihm verwendeten Geräts auf eine geschützte Ressource in der Applikation eines Service Providers (SP) zugreifen. Der Service Provider erkennt, dass es sich um einen nicht-authentifizierten Benutzer handelt und antwortet mit einem OIDC Authentifizierungsrequest und einer Weiterleitung zum Identity Provider (IdP) des ID Austria Systems. Das nachfolgende Beispiel zeigt einen OIDC Authentifizierungsrequest für die Applikation: https://eid.a-sit.at/notes

https://eid.oesterreich.gv.at/auth/idp/profile/oidc/authorize?
response_type=code&client_id=https%3A%2F%2Feid.a-sit.at%2Fnotes&scope=openid%20profile&state=5c7d29a1-48f2-416e-b25a-
93a9b515c562&reclient_id=https%3A%2F%2Feid.a-sit.at%2Fnotes%2Foauth2%2Fredirect

• response_type: Der Response Typ muss mit „code“ angegeben werden da vom ID Austria System nur der Authorization Code Flow unterstützt wird.
• client_id: Der eindeutige Identifikator der SP Applikation, die am ID Austria System registriert sein muss. Das ID Austria System fordert als client_id eine URL welche im Kontext der Anwendung liegen muss.
• scope: Definiert in OIDC das Set von Identitätsinformationen welche vom IDP angefordert werden. Im ID Austria System erfolgt die Anforderung von Attributen über das Applikationsregister des ID Austria und somit wird in diesem Zusammenhang empfohlen die Scopes openid und profile anzufragen.
• redirect_uri: Die Redirect URI definiert die Client-Callback URI an welche das ID Austria System die Authentication Response an den SP ausliefern soll.
• state: Optionaler jedoch empfohlener Parameter als CSFR / XSRF Schutz um den State zwischen Request und Callback beizubehalten.

2. Der IdP führt die Authentifizierung mit dem Benutzer durch. Die einzelnen Schritte für die Identifikation und Authentifizierung des Benutzers unterscheiden sich nicht zu den für SAML2 beschriebenen Schritten 3 bis 7.

3. Nach einer erfolgreichen Authentifizierung antwortet der IdP mit einem Berechtigungscode als Authentifizierungsresponse, der über das Gerät des Benutzers an die SP Applikation weitergeleitet wird. Technisch erfolgt diese Weiterleitung an die Redirect URI entsprechend der OIDC Spezifikation.

https://eid.a-sit.at/notes/oauth2/redirect?
code=AAdzZWNyZXQxWrRnkI...&state=5c7d29a1-48f2-416e-b25a-
93a9b515c562

4. Die SP Anwendung sendet den Berechtigungscode zusammen mit einer Client-Id und einem Client Secret in einem Token-Request an den Token Service des IdP um das eigentliche signierte idToken und somit die Identifikationsdaten des Benutzers aus dem ID Austria System zu erhalten. Eine Authentifizierung des Clients gegenüber dem IDP ist im ID Austria System verpflichtet und somit muss ein Client Secret verwendet werden.

5. Der IdP validiert den Token-Request und antwortet mit einer Token-Response und dem vom ID Austria signierten idToken. Nach erfolgreicher Validierung der Token-Response durch den SP ist der Benutzer angemeldet.

ID Austria Integration mittels OIDC auf mobilen Geräten

Die Verwendung des ID Austria auf mobilen Endgeräten unterscheidet sich aus Sicht des OpenID Connect Authentifizierungsprotokolls nur geringfügig von dem bereits zuvor geschriebenen Authorization Code Flow für OIDC. Der Unterschied im Authentifizierungsprotokoll ergibt sich aus der Empfehlung zur Unterstützung des RFC8252 – OAuth 2.0 for Native Apps und der damit einhergehenden Integration von RFC7636 – Proof Key for Code Exchange by OAuth Public Clients zur bessern Absicherung der Kommunikation zwischen mobiler App und dem ID Austria System.

Da das ID Austria System jedoch auch über eine mobile Komponente „ID Austria App“ verfügt, welche am mobilen Gerät installiert und aktiviert sein kann, ergeben sich aus Sicht des Benutzers und der am Anmeldeprozess involvierten Komponenten Unterschiede je nach dem welche Apps am mobilen Gerät nun tatsächlich zur Verfügung stehen.

Anmeldeprozess mit ID Austria App

Dieser Prozessfluss beschreibt die Authentifizierung eines Benutzers mit installierter und aktivierter ID Austria App unter Verwendung des zur beschriebenen OIDC Authorization Code Flow. Eine Darstellung der einzelnen Prozessschritte ist in Abbildung 4 gegeben.

1. Die SP App möchte auf eine geschützte Ressource in einer Serverkomponente (Applikation) des Service Providers zugreifen. Ein praktisches Beispiel ist der Zugriff auf ein REST Service des SP welches Daten für die SP App und somit dem Benutzer bereitstellt.

2. Die Serverkomponente des SP erkennt, dass es sich um einen nicht-authentifizierten Benutzer handelt und antwortet mit einem Authentifizierungsrequest welcher den Benutzer zum IdP des ID Austria System weiterleitet.

3. Die SP App öffnet die URL mit dem Authentifizierungsrequest an den IDP. Da im aktuell beschriebenen Szenario eine ID Austria App (Digitales-Amt-App) verfügbar ist, welche entsprechend RFC8252 Kapitel 7.2 auf die https URL des ID Austria Systems registriert ist, wird die URL in der ID Austria App geöffnet.

Hinweis: Wird bei der SP Registrierung unter Generelle Informationen die Option App2App aktiviert und ist am Mobilgerät keine ID Austria App verfügbar, wird ein Anmeldeprozess mittels mobilen Browser unterbunden. Soll der Browser Login generell unterbunden werden, liegt dies in der Umsetzung des jeweiligen SPs (bspw. über einen App-spezifischen http Header der am SP backend geprüft wird).

4. Die ID Austria App erkennt den Authentifizierungsrequest und startet einen Authentifizierungsvorgang für den Benutzer in der Digitales-Amt App. Hierfür wird der Authentifizierungsrequest an den Shibboleth IDP des ID Austria Systems weitergeleitet. Der IdP antwortet mit einer Auswahl an möglichen Anmeldeoptionen, wie in Abbildung 5 dargestellt. Hier wählt der Benutzer „Anmelden mit ID Austria“ aus.

5. Der IdP leitet den Benutzer zur Authentifizierung an den VDA weiter.

6. Der VDA führt die Authentifizierung mit dem Benutzer durch wobei diese vollständig in der ID Austria App durchgeführt wird. Die einzelnen Schritte für die Identifikation und Authentifizierung des Benutzers sind ähnlich zu den in für SAML2 beschriebenen Schritten 3 bis 7. Es ist jedoch keine Push Notification an die ID Austria App notwendig, da sich der Benutzer bereits in der ID Austria App befindet, was sich aus sich des Benutzer in einem durchgehenden Prozess in der ID Austria App widerspiegelt.

7. Nach einer erfolgreichen Authentifizierung retourniert der IdP einen Authorization Code (Berechtigungscode) über den User Agent des Benutzers via einem Redirect an die Redirect-URI des SP. Die ID Austria App löst den Redirect des IdP auf und sendet die Response zur SP App.

Um die Authentifizierungsresponse in der mobilen App des SP zu empfangen spezifiziert RFC8252 – Receiving the Authorization Response in a Native App mehrere Möglichkeiten um die SP App auf eine RedirectURL zu registrieren. Diese werden durch das ID Austria System unterstützt wobei empfohlen wird https basierte Redirects zu verwenden da für diese aus aktueller Sicht eine gute Unterstützung auf unterschiedlichen mobilen Plattformen existiert

8. Nach Empfang der Authentifizierungsrespose in der mobilen App des SP kann diese den OIDC Berechtigungscode und optionale weitere Parameter an die Serverkomponente des SP weiterleiten. Die Serverkomponente kann den Berechigungscode entsprechend dem Authorization Code Flow gegen das OIDC IdToken mit den Benutzerinformationen tauschen und den Benutzer am Service anmelden. Eine Authentifizierung der Serverkomponente des SP gegenüber dem IDP ist im ID Austria System verpflichtet und somit muss an dieser Stelle ein Client Secret verwendet werden.