Openid - Versionsgeschichte

Niklas.guenauer: /* Sicherheitsaspekte */

2021-06-10T12:26:52Z

Sicherheitsaspekte

Thomas.will: /* Details zur Nutzung */

2021-06-10T11:54:54Z

Details zur Nutzung

Thomas.will: /* Details zur Nutzung */

2021-06-10T11:49:39Z

Details zur Nutzung

Thomas.will: /* Grundprinzip */

2021-06-09T11:18:14Z

Grundprinzip

Thomas.will: /* Grundprinzip */

2021-06-09T11:18:08Z

Grundprinzip

Thomas.will: /* Grundprinzip */

2021-06-09T11:10:30Z

Grundprinzip

Thomas.will: Die Seite wurde neu angelegt: „=Was ist OpenID= englisch für offene Identifikation dezentrales Authentifizierungssystem für webbasierte Dienste *Nutzer meldet sich beim OpenID-Provider e…“

2021-06-09T11:07:47Z

Die Seite wurde neu angelegt: „=Was ist OpenID= *englisch für offene Identifikation *dezentrales Authentifizierungssystem für webbasierte Dienste *Nutzer meldet sich beim OpenID-Provider e…“

Neue Seite

=Was ist OpenID=
*englisch für offene Identifikation
*dezentrales Authentifizierungssystem für webbasierte Dienste
*Nutzer meldet sich beim OpenID-Provider einmal an.
*Bekommt eine URL, Identifier genannt
*Anmeldung bei unterstützenden Websites(Relying Parties)
*Single-Sign-on-Prinzip
*Dezentral angelegt
*Konzept der URL-basierten Identität um.
=Grundprinzip=
Für die Anmeldung mit OpenID wird eine OpenID-Identität benötigt. Diese wird durch einen OpenID-Anbieter bereitgestellt. Aufgrund seiner dezentralen Architektur gibt es viele verschiedene OpenID-Anbieter. Da das Protokoll offengelegt ist,[2] existieren Implementierungen in vielen Programmiersprachen. Die ausschließlich unter Open-Source-Lizenzen gestellte Software kann auf einem eigenen Server installiert werden. Somit ist es jedem mit relativ geringem Aufwand möglich, selbst zum OpenID-Anbieter zu werden. Viele Webseiten bieten aufgrund dieses Umstands zu ihren Benutzerkonten zusätzlich OpenID-Identitäten an.

Eine OpenID hat die Form einer URL. Üblicherweise ist der Benutzername eine Subdomain des OpenID-Anbieters: benutzername.example.com. Einige Anbieter verwenden auch den Benutzernamen als Pfad in der URL: example.com/benutzername. Um mit seiner OpenID anbieterunabhängig zu sein, empfiehlt sich die Verwendung einer eigenen URL auf eigenem Webspace als OpenID (Delegation).

Webseiten, die OpenID als Anmeldeverfahren unterstützen, können ergänzend zur OpenID-Anmeldung weiterhin eine klassische Anmeldung (Benutzername mit zugehörigem Passwort) anbieten. Wird auf die klassische Anmeldung verzichtet, so müssen keine Funktionen wie „Passwort vergessen“ implementiert werden. Weiterhin entfällt auf Seiten des Webseitenbetreibers durch die nicht mehr zu speichernden Benutzernamen und Passwörter der dafür nötige Sicherheitsaufwand, welcher sich auf den OpenID-Anbieter verlagert.

Details zur Nutzung
Eine OpenID kann bereits bei der Registrierung eines neuen Benutzerkontos bei einer Webseite angegeben werden, die die Anmeldung mit OpenID unterstützt. Dabei kann der Webseitenbetreiber mit der OpenID Simple Registration neun[3] grundlegende Informationen vom OpenID-Anbieter erhalten, wenn der OpenID-Benutzer diesem Prozess zustimmt und die entsprechenden Informationen zuvor beim OpenID-Anbieter hinterlegt hat. Somit ist es nicht mehr zwingend erforderlich, bei jeder OpenID-fähigen Webseite im Rahmen der Registrierung E-Mail-Adresse und Namen anzugeben. Nicht immer werden von Webseitenbetreibern alle neun[3] möglichen Informationen auch tatsächlich verwendet. Der Nachteil einer ausschließlichen OpenID-Nutzung besteht im Gegenzug darin, dass klassische Elemente wie Benutzernamen häufig nicht verwendet werden können, sodass eine vollständige Registrierung vorgezogen wird.

Bei einem vorhandenen „klassischen“ Benutzerkonto einer OpenID-fähigen Seite ist es meist möglich, OpenIDs nachträglich anzugeben oder zu entfernen. Sobald eine OpenID erfolgreich mit dem Benutzerkonto verbunden wurde, kann diese anstelle der üblichen Anmeldung mit Benutzername und Passwort verwendet werden.

Für den Nutzer ist es durch die OpenID-Architektur einfacher, eine Loginseite auf Echtheit zu überprüfen, da er sich die sicherheitsrelevanten Merkmale nur einer einzigen Loginseite merken muss, statt von mehreren, wie es ohne Single Sign-on der Fall ist. Die OpenID-Provider sorgen ebenfalls für mehr Sicherheit, indem sie etwa Cookies setzen, ein individuelles Bild zeigen, den HTTP-Referer mit der IP des Requesters vergleichen oder ein clientseitiges TLS-Zertifikat zur Authentifizierung nutzen. Insbesondere letzteres wird von immer mehr Providern unterstützt.

Für das OpenID-Anmeldeverfahren wird der Benutzer auf die Anmeldeseite des OpenID-Anbieters geleitet, auf der die Anmeldung erfolgt. Aus Sicherheitsgründen erscheint eine weitere, auf die anfragende hinweisende Seite, die bestätigt werden muss. Wenn die für die Anmeldung erforderliche Seite vom Benutzer als vertrauenswürdig gekennzeichnet wurde, kann die Bestätigungsseite bei einigen OpenID-Anbietern deaktiviert werden, sodass sie bei weiteren OpenID-Anmeldungen nicht mehr angezeigt wird. Nach der Anmeldebestätigung beim OpenID-Anbieter wird der Benutzer im angemeldeten Zustand auf die eigentliche Webseite zurückgeleitet. Der Anmeldedatenaustausch kann dergestalt stattfinden, dass die Webseite bis zu neun Informationen des verbundenen OpenID-Kontos bei jeder Anmeldung erhält und somit immer auf dem neuesten Stand ist. Der Benutzer muss diese Grundinformationen somit nur noch beim OpenID-Anbieter pflegen. Der Benutzer kann auch dauerhaft seine Zustimmung zur Datenübertragung an die Webseite geben und muss diese dann nicht mehr bei jeder Anmeldung angeben.

Teilweise haben OpenID-Anbieter und OpenID-fähige Webseitenbetreiber zusätzlich zur Simple Registration auch das neuere OpenID-Attribute-Exchange-Protokoll zum erweiterten Datenaustausch implementiert. Dann werden die Daten übertragen, die von jeweils beiden unterstützt werden. Auch hier gilt, dass der Benutzer die volle Kontrolle über seine Daten und deren Weitergabe hat.

@@ Zeile 33: / Zeile 33: @@
 *Sicherer da Cookies gesetzt , ein individuelles Bild zeigen, den HTTP-Referer mit der IP des Requesters vergleichen oder ein
 *Sicherer da ein clientseitiges TLS-Zertifikat zur Authentifizierung genutzt werden kann.
+*Nutzer wird zum OpenID Anbieter weitergeleitet und muss angeforderte Rechte der app akzeptieren. Abfrage kann einmalig oder mehrmals auftreten.
 Für das OpenID-Anmeldeverfahren wird der Benutzer auf die Anmeldeseite des OpenID-Anbieters geleitet, auf der die Anmeldung erfolgt. Aus Sicherheitsgründen erscheint eine weitere, auf die anfragende hinweisende Seite, die bestätigt werden muss. Wenn die für die Anmeldung erforderliche Seite vom Benutzer als vertrauenswürdig gekennzeichnet wurde, kann die Bestätigungsseite bei einigen OpenID-Anbietern deaktiviert werden, sodass sie bei weiteren OpenID-Anmeldungen nicht mehr angezeigt wird. Nach der Anmeldebestätigung beim OpenID-Anbieter wird der Benutzer im angemeldeten Zustand auf die eigentliche Webseite zurückgeleitet. Der Anmeldedatenaustausch kann dergestalt stattfinden, dass die Webseite bis zu neun Informationen des verbundenen OpenID-Kontos bei jeder Anmeldung erhält und somit immer auf dem neuesten Stand ist. Der Benutzer muss diese Grundinformationen somit nur noch beim OpenID-Anbieter pflegen. Der Benutzer kann auch dauerhaft seine Zustimmung zur Datenübertragung an die Webseite geben und muss diese dann nicht mehr bei jeder Anmeldung angeben.
 Teilweise haben OpenID-Anbieter und OpenID-fähige Webseitenbetreiber zusätzlich zur Simple Registration auch das neuere OpenID-Attribute-Exchange-Protokoll zum erweiterten Datenaustausch implementiert. Dann werden die Daten übertragen, die von jeweils beiden unterstützt werden. Auch hier gilt, dass der Benutzer die volle Kontrolle über seine Daten und deren Weitergabe hat.

@@ Zeile 29: / Zeile 29: @@
 *Oft kann man klassische Elemente wie Benutzernamen häufig nicht verwendet.
 *Man kann auch eine herkömmliches Konto später mit einer OpenID Konto verbunden.
+=Sicherheitsaspekte=
 Für das OpenID-Anmeldeverfahren wird der Benutzer auf die Anmeldeseite des OpenID-Anbieters geleitet, auf der die Anmeldung erfolgt. Aus Sicherheitsgründen erscheint eine weitere, auf die anfragende hinweisende Seite, die bestätigt werden muss. Wenn die für die Anmeldung erforderliche Seite vom Benutzer als vertrauenswürdig gekennzeichnet wurde, kann die Bestätigungsseite bei einigen OpenID-Anbietern deaktiviert werden, sodass sie bei weiteren OpenID-Anmeldungen nicht mehr angezeigt wird. Nach der Anmeldebestätigung beim OpenID-Anbieter wird der Benutzer im angemeldeten Zustand auf die eigentliche Webseite zurückgeleitet. Der Anmeldedatenaustausch kann dergestalt stattfinden, dass die Webseite bis zu neun Informationen des verbundenen OpenID-Kontos bei jeder Anmeldung erhält und somit immer auf dem neuesten Stand ist. Der Benutzer muss diese Grundinformationen somit nur noch beim OpenID-Anbieter pflegen. Der Benutzer kann auch dauerhaft seine Zustimmung zur Datenübertragung an die Webseite geben und muss diese dann nicht mehr bei jeder Anmeldung angeben.
 Teilweise haben OpenID-Anbieter und OpenID-fähige Webseitenbetreiber zusätzlich zur Simple Registration auch das neuere OpenID-Attribute-Exchange-Protokoll zum erweiterten Datenaustausch implementiert. Dann werden die Daten übertragen, die von jeweils beiden unterstützt werden. Auch hier gilt, dass der Benutzer die volle Kontrolle über seine Daten und deren Weitergabe hat.

@@ Zeile 25: / Zeile 25: @@
 =Details zur Nutzung=
 *Überlicherweise wird bei der Anmeldung schon OpenID mit angeboten.
-*Webseitenbetreiber mit der OpenID Simple Registration neun[3] grundlegende Informationen vom OpenID-Anbieter erhalten, wenn der OpenID-Benutzer diesem Prozess zustimmt und die entsprechenden Informationen zuvor beim OpenID-Anbieter hinterlegt hat. Somit ist es nicht mehr zwingend erforderlich, bei jeder OpenID-fähigen Webseite im Rahmen der Registrierung E-Mail-Adresse und Namen anzugeben. Nicht immer werden von Webseitenbetreibern alle neun[3] möglichen Informationen auch tatsächlich verwendet. Der Nachteil einer ausschließlichen OpenID-Nutzung besteht im Gegenzug darin, dass klassische Elemente wie Benutzernamen häufig nicht verwendet werden können, sodass eine vollständige Registrierung vorgezogen wird.
+*Webseitenbetreiber mit der OpenID Simple Registration neun grundlegende Informationen vom
+*Wenn man OpenID nutzt, muss man keine eigenen Authentifizierungsmechanismus einrichten.
-Bei einem vorhandenen „klassischen“ Benutzerkonto einer OpenID-fähigen Seite ist es meist möglich, OpenIDs nachträglich anzugeben oder zu entfernen. Sobald eine OpenID erfolgreich mit dem Benutzerkonto verbunden wurde, kann diese anstelle der üblichen Anmeldung mit Benutzername und Passwort verwendet werden.
+*Oft kann man klassische Elemente wie Benutzernamen häufig nicht verwendet.
 Für den Nutzer ist es durch die OpenID-Architektur einfacher, eine Loginseite auf Echtheit zu überprüfen, da er sich die sicherheitsrelevanten Merkmale nur einer einzigen Loginseite merken muss, statt von mehreren, wie es ohne Single Sign-on der Fall ist. Die OpenID-Provider sorgen ebenfalls für mehr Sicherheit, indem sie etwa Cookies setzen, ein individuelles Bild zeigen, den HTTP-Referer mit der IP des Requesters vergleichen oder ein clientseitiges TLS-Zertifikat zur Authentifizierung nutzen. Insbesondere letzteres wird von immer mehr Providern unterstützt.

@@ Zeile 16: / Zeile 16: @@
 *Kann auf einem eigenen Server installiert werden.
 *Viele Webseiten bieten zusätzlich OpenID-Identitäten an.
-=OpenID
+=OpenID=
 *OpenID hat die Form einer URL.
 *Benutzername eine Subdomain des OpenID-Anbieters: benutzername.example.com
@@ Zeile 22: / Zeile 22: @@
 *klassische Anmeldung wird alternativ angeboten.
 *Wird auf die klassische Anmeldung verzichtet entfällt Sicherheitsaufwand
 =Details zur Nutzung=
 *Überlicherweise wird bei der Anmeldung schon OpenID mit angeboten.

@@ Zeile 16: / Zeile 16: @@
 *Kann auf einem eigenen Server installiert werden.
 *Viele Webseiten bieten zusätzlich OpenID-Identitäten an.
+=OpenID
-Eine OpenID hat die Form einer URL. Üblicherweise ist der Benutzername eine Subdomain des OpenID-Anbieters: benutzername.example.com. Einige Anbieter verwenden auch den Benutzernamen als Pfad in der URL: example.com/benutzername. Um mit seiner OpenID anbieterunabhängig zu sein, empfiehlt sich die Verwendung einer eigenen URL auf eigenem Webspace als OpenID (Delegation).
+*OpenID hat die Form einer URL.
+*Benutzername eine Subdomain des OpenID-Anbieters: benutzername.example.com
-Webseiten, die OpenID als Anmeldeverfahren unterstützen, können ergänzend zur OpenID-Anmeldung weiterhin eine klassische Anmeldung (Benutzername mit zugehörigem Passwort) anbieten. Wird auf die klassische Anmeldung verzichtet, so müssen keine Funktionen wie „Passwort vergessen“ implementiert werden. Weiterhin entfällt auf Seiten des Webseitenbetreibers durch die nicht mehr zu speichernden Benutzernamen und Passwörter der dafür nötige Sicherheitsaufwand, welcher sich auf den OpenID-Anbieter verlagert.
+*Anbieter verwenden auch den Benutzernamen als Pfad in der URL: example.com/benutzername.
+*klassische Anmeldung wird alternativ angeboten.
-Details zur Nutzung
+*Wird auf die klassische Anmeldung verzichtet entfällt Sicherheitsaufwand
-Eine OpenID kann bereits bei der Registrierung eines neuen Benutzerkontos bei einer Webseite angegeben werden, die die Anmeldung mit OpenID unterstützt. Dabei kann der Webseitenbetreiber mit der OpenID Simple Registration neun[3] grundlegende Informationen vom OpenID-Anbieter erhalten, wenn der OpenID-Benutzer diesem Prozess zustimmt und die entsprechenden Informationen zuvor beim OpenID-Anbieter hinterlegt hat. Somit ist es nicht mehr zwingend erforderlich, bei jeder OpenID-fähigen Webseite im Rahmen der Registrierung E-Mail-Adresse und Namen anzugeben. Nicht immer werden von Webseitenbetreibern alle neun[3] möglichen Informationen auch tatsächlich verwendet. Der Nachteil einer ausschließlichen OpenID-Nutzung besteht im Gegenzug darin, dass klassische Elemente wie Benutzernamen häufig nicht verwendet werden können, sodass eine vollständige Registrierung vorgezogen wird.
+=Details zur Nutzung=
 Bei einem vorhandenen „klassischen“ Benutzerkonto einer OpenID-fähigen Seite ist es meist möglich, OpenIDs nachträglich anzugeben oder zu entfernen. Sobald eine OpenID erfolgreich mit dem Benutzerkonto verbunden wurde, kann diese anstelle der üblichen Anmeldung mit Benutzername und Passwort verwendet werden.

@@ Zeile 9: / Zeile 9: @@
 *Konzept der URL-basierten Identität um.
 =Grundprinzip=
-Für die Anmeldung mit OpenID wird eine OpenID-Identität benötigt. Diese wird durch einen OpenID-Anbieter bereitgestellt. Aufgrund seiner dezentralen Architektur gibt es viele verschiedene OpenID-Anbieter. Da das Protokoll offengelegt ist,[2] existieren Implementierungen in vielen Programmiersprachen. Die ausschließlich unter Open-Source-Lizenzen gestellte Software kann auf einem eigenen Server installiert werden. Somit ist es jedem mit relativ geringem Aufwand möglich, selbst zum OpenID-Anbieter zu werden. Viele Webseiten bieten aufgrund dieses Umstands zu ihren Benutzerkonten zusätzlich OpenID-Identitäten an.
+*OpenID-Identität wird benötigt.
 Eine OpenID hat die Form einer URL. Üblicherweise ist der Benutzername eine Subdomain des OpenID-Anbieters: benutzername.example.com. Einige Anbieter verwenden auch den Benutzernamen als Pfad in der URL: example.com/benutzername. Um mit seiner OpenID anbieterunabhängig zu sein, empfiehlt sich die Verwendung einer eigenen URL auf eigenem Webspace als OpenID (Delegation).

Openid - Versionsgeschichte

Niklas.guenauer: /* Sicherheitsaspekte */

Thomas.will: /* Details zur Nutzung */

Thomas.will: /* Details zur Nutzung */

Thomas.will: /* Grundprinzip */

Thomas.will: /* Grundprinzip */

Thomas.will: /* Grundprinzip */

Thomas.will: Die Seite wurde neu angelegt: „=Was ist OpenID= *englisch für offene Identifikation *dezentrales Authentifizierungssystem für webbasierte Dienste *Nutzer meldet sich beim OpenID-Provider e…“

Thomas.will: Die Seite wurde neu angelegt: „=Was ist OpenID= englisch für offene Identifikation dezentrales Authentifizierungssystem für webbasierte Dienste *Nutzer meldet sich beim OpenID-Provider e…“