Anbindung via OpenID Connect

Die Umsetzung erfolgt gemäß der OIDC Spezifikationen.
Weitere Informationen stehen unter diesem Link zur Verfügung: OIDC Spezifikationen

E-ID spezifische Claims sind gemäß dem PVP2 Attribut-Profil umgesetzt.
Link zum PVP2 Attribut-Profil: (Draft folgt in Kürze)

Im Gegensatz zu SAML2, können im E-ID System mit OIDC auch App2App-basierte Authentifizierungsvarianten umgesetzt werden. (Native) Mobile Apps können somit via OIDC eine Anmeldung mittels E-ID integrieren. Was für mobile Apps speziell zu beachten ist, ist im zweiten Abschnitt beschrieben.

Anmeldung mittels OIDC

Eine E-ID Anmeldung mittels OIDC kann in sämtlichen Szenarien durchgeführt werden. Beispiele dafür sind:

  • mit einem herkömmlichen Web-Browser auf einem PC/Laptop
  • mit einer nativen App
  • mit einem mobilen Browser auf einem Smartphone

Hinweis: Wird die E-ID Anmeldung auf einem mobilen Gerät durchgeführt, ist der Prozessfluss der Authentifizierung für den Benutzer davon abhängig, ob die E-ID App am Smartphone installiert und initialisiert ist. Ob die E-ID App installiert ist, oder nicht, hat keine Auswirkungen auf den Prozessfluss der OIDC Implementierung beim SP.

Bei jeder OIDC Anmeldung wird ein Authentifizierungsrequest an den IdP geschickt. Dieser wird üblicherweise direkt vom Client (Browser, App) als HTTP GET Request an den IdP geschickt.

Es wird hier beispielhaft der Authorization Code Flow Prozessfluss beschrieben.

Beispiel für einen Authentifizierungsrequest eines OIDC Authorization Code Flows:

GET https://egiz.gv.at/idp/profile/oidc/authorize?response_type=code&client_id=274582323476.beispielservice.at&redirect_uri=https://beispielservice.at/openID/securearea.action&scope=openid+profile+eid&state=1234567890 HTTP/1.1

Hinweis: Zulässige Parameter für scope und response_type siehe Abschnitt Registrierung

Anschließend antwortet der IdP dem Client mit einer Auswahl an Möglichkeiten zur Authentifizierung (VDA oder ggf. eIDAS, wenn vom SP konfiguriert), wie in Abbildung 1 dargestellt.

Abbildung 1: Auswahl der Authentifizierungsvariante

Nach einer erfolgreichen Authentifizierung am IdP, antwortet dieser dem Client mit einer (erfolgreichen) Authentication Response, die den verschlüsselten Authorization Code gemäß dem OIDC Authorization Code Flow beinhaltet.

Beispiel für eine erfolgreiche Authentication Response vom IdP:

 HTTP/1.1 302 Found
  Location: https://beispielservice.at/cb?code=QXV0aEhhbmRsZXIxfDIwMjA...&state=af0ifjsldkj

Beispiel für einen entschlüsselten Authorization Code:

AuthHandler1|2020-03-30 13:59:18 514|c046d79a-cc9d-4439-827b-30e5190e2445|lmbEBJwRjb9ecFn65U5FCTjvIJE=

Der Authorization Code wird im Anschluss (üblicherweise vom SP Backend Service) in einem Token-Request an den Token-Endpoint des IdP gesendet, zusammen mit einem registrierten Client-Secret, falls erforderlich.

Beispiel für einen OIDC Token-Request:


POST https://eid.egiz.gv.at/idp/Authn/authhandler?code&code=QXV0aEhhbmRsZXIxfDIwMjAtMDMtMzAgMTM6NTk6MTggNTE0fGMwNDZkNzlhLWNjOWQtNDQzOS04MjdiLTMwZTUxOTBlMjQ0NXxsbWJFQkp3UmpiOWVjRm42NVU1RkNUanZJSkU9 HTTP/1.1

Im Body des Post Requests werden die Parameter 'code', 'grant_type', 'client_secret' (falls erforderlich), 'redirect_uri' und die 'client_id' übermittelt.

code=QXV0aEhhbmRsZXIxfDIwMjAtMDMtMzAgMTM6NTk....&grant_type=authorization_code&client_secret=secret&redirect_uri=https://beispielservice.at/openID/securearea.action&client_id=274582323476.beispielservice.at

Nach erfolgreicher Validierung des Authorization Codes durch den IdP, antwortet dieser mit einer OIDC Successful Token Response, die das ID-Token enthält. Dieses ID-Token liefert die angeforderten Attribute (Claims) in Form eines JSON Web Tokens.

Beispiel für ein OIDC Successful Token Response vom IdP:

HTTP/1.1 200 OK
  Content-Type: application/json

   "access_token": "SlAV32hkKG",
   "token_type": "Bearer",
   "refresh_token": "8xLOxBtZp8",
   "expires_in": 3600,
      "id_token": 
     "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
     yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
     NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
     fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
     AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
     Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
     NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
     QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
     K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
     XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"

Beispiel für einen unverschlüsselten OIDC Token:

{
"kid": "defaultRSASign",
"alg": "RS256"
"}.{"
"at_hash": "TLaXJ0KKqSX7awjCtW7Ozw",
"sub": "ZP-MH:DJ6nGg2JgcPH768BhqTNXVsGhOY=","urn:pvpgvat:oidc.eid_issuing_nation": "AT",
"birthdate": "1940-01-01",
""urn:pvpgvat:oidc.eid_citizen_qaa_eidas_level": "http://eidas.europa.eu/LoA/substantial",
"urn:pvpgvat:oidc.eid_online_identity_link": "ew0K…",
"iss": "https://eid.egiz.gv.at",
"iss": "given_name": "Max",
"aud": "https://beispielService.at/openID/",
"urn:pvpgvat:oidc.eid_sector_for_identifier": "urn:publicid:gv.at:cdid+ZP-MH",
"auth_time": 1585232055,
"urn:pvpgvat:oidc.bpk": "ZP-MH:DJ6nGg2JgcPH768BhqTNXVsGhOY=",
"urn:pvpgvat:oidc.eid_signer_certificate": "MIIF1…",
"exp": 1585235656,
"iat": 1585232056,
"family_name": "Mustermann"
}.{
JqqwDQO…
"token_type":"Bearer","expires_in":600
}

Folgender Link stellt eine detaillierte Beschreibung der Prozessschritte bei einer OIDC Anmeldungen bereit:
Detaillierter Prozessfluss für OIDC Anmeldungen in Web Browser Anwendungen

Verwendung von OIDC in nativen Apps

Die Verwendung von OIDC ist grundsätzlich in allen Varianten ähnlich, d.h. unabhängig davon ob OIDC in einem Browser-basierten Flow verwendet wird oder in einem App2App Szenario bei der Integration der E-ID Anmeldung in einer nativen App. Jedoch gilt es für das App2App Szenario folgende Punkte zu beachten:

Wird OIDC in eine native App integriert, kann als Rücksprung-adresse (redirect_uri) auch ein App/URL Scheme angegeben werden, sodass nach der Anmeldung ein unmittelbarer Rücksprung in die App erfolgt.

Beispiel: com.example.app:/oauth2redirect/example-provider

Bei der Verwendung von OIDC in nativen Apps empfiehlt RFC8252 die Verwendung des Code Authorization Flows, da nur dieser Flow mit PKCE (RFC7636) abgesichert werden kann.

Hinweis: Eine Verwendung von PKCE in nativen Apps wird aus Sicherheitsgründen sehr empfohlen.