Anbindung via OpenID Connect

Das ID Austria System stellt OpenID Connect (OIDC) gemäß der OpenID Connect Spezifikation bereit. Die nachfolgende Beschreibung zeigt eine Anbindung einer Anwendung mittels OIDC am ID Austria System. Detailierte Beschreibungen zu OpenID Connect stehen unter dem nachfolgenden Link zur Verfügung: OIDC Spezifikationen

ID Austria spezifische Eigenschaften für OIDC

  • Vom ID Austria System werden wird ausschließlich der Authorization Code Flow (Response-Type: code) entsprechend der OIDC Spezifikation unterstützt. 
  • Eine Authentifizierung des Service Provider / Client mittels client_secret ist verpflichtend.
  • Das ID Austria System fordert als client_id eine URL welche im Kontext der Anwendung liegen muss.
  • 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.
  • Zusätzlich zu den in OIDC spezifizierten Claims, welche im Scope „profile“ definiert sind, unterstützt das ID Austria System spezifische Claims. Diese Claims sind gemäß dem PVP2 Attribut-Profil umgesetzt und sind dem OIDC Scope „profile“ zugeordnet.
    Link zum PVP2 Attribut-Profil: PVP2 Attribut-Profil

(Draft folgt in Kürze)

Die OpenID Connect Anbindung im ID Austria System steht sowohl für klassische Browser basierte Anwendung als auch für Applikationen auf mobilen Geräten zur Verfügung.  (Native) Mobile Apps können somit via OIDC eine Anmeldung mittels ID Austria integrieren. Was für mobile Apps speziell zu beachten ist, ist im zweiten Abschnitt beschrieben.

Anmeldung mittels OIDC

Eine ID Austria 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 ID Austria Anmeldung auf einem mobilen Gerät durchgeführt, ist der Prozessfluss der Authentifizierung für den Benutzer davon abhängig, ob die ID Austria App am Smartphone installiert und initialisiert ist. Ob die ID Austria 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  oder HTTP POST Request an den IdP gesendet.

OIDC Endpunkte des Produktionssystems:

Authorization Endpoint: https://eid.oesterreich.gv.at/auth/idp/profile/oidc/authorize

Token Endpoint: https://eid.oesterreich.gv.at/idp/profile/oidc/token

Userinfo Endpoint: https://eid.oesterreich.gv.at/auth/idp/profile/oidc/userinfo

JWKs URI: https://eid.oesterreich.gv.at/auth/idp/profile/oidc/keyset

Beispiel für einen Authentifizierungsrequest bei Verwendung des OIDC Authorization Code Flow:

https://eid.oesterreich.gv.at/auth/idp/profile/oidc/authorize?response_type=code
&client_id=https%3A%2F%2Fbeispielservice.at
&redirect_uri=https%3A%2F%2Fbeispielservice.at%2Fcb
&scope=openid+profile+eid&state=1234567890
  • 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.

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 (ID Austria via VDA oder ggf. eIDAS, wenn vom SP konfiguriert), wie in Abbildung 1 dargestellt.

Login mittels E-ID
Abbildung 1: Auswahl der Authentifizierungsvariante

Nach einer erfolgreichen Authentifizierung am IdP, antwortet dieser dem Client mit einer (erfolgreichen) Authentication Response, die den 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

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.

Beispiel für einen OIDC Token-Request:

POST https://eid.oesterreich.gv.at/auth/idp/profile/oidc/token
HTTP/1.1

Im Body des Post Requests werden die Parameter ‚code‘, ‚grant_type‘, ‚client_secret‘, ‚redirect_uri‘ und die ‚client_id‘ übermittelt. Die Verwendung eines ‚client_secrets‘ ist auf jeden Fall verpflichtend und unabhängig davon ob der Flow mit PKCE (RFC7636) abgesichert wurde oder nicht.

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

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

Beispiel für ein OIDC Successful Token Response vom IdP
die vollständige Response finden sie hier:

{  
   "token_type": "Bearer",
   "expires_in": 3600,
   "id_token": "eyJraWQiOiJkZWZhdWx0UlNBU2lnbiIsIm.....",
}

Beispiel für dekodiertes mit JWS signiertes OIDC idToken:
die vollständige idToken ohne JWS Signaturteil finden sie hier:

{
   "kid": "defaultRSASign",
   "alg": "RS256"
}.{
  "at_hash": "-alxxY8YP3MVTrpeVzANVw",
  "sub": "ZP-MH:KQMY8Sl9WsmBxrYrYOiFS2VkLyo=",
  "urn:pvpgvat:oidc.eid_issuing_nation": "AT",
  "birthdate": "1983-06-04",
  "urn:pvpgvat:oidc.pvp_version": "2.1",
  "iss": "https://eid.egiz.gv.at",
  "given_name": "XXXŐzgür",
   ...
}.
  qqwDQO…

Die oben dargestellte JWS Signatur beinhaltet den:

  • JWS Signaturheader mit Informationen zum Signaturalgorithmus, …
  • PayLoad welche die Attribute des Benutzer und weitere Authentifizierungsmerkmale beinhaltet
  • JWS Signaturwert

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 ID Austria 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 URL Scheme angegeben werden, sodass nach der Anmeldung ein unmittelbarer Rücksprung in die App erfolgt.

Beispiel: https://beispielservice.at/cb

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.

Weitere Details zur Verwendung von OIDC in mobilen Applikationen finden sich auch in den Hintergrundinformationen.