Bevor wir mit der Integration beginnen können, muss das Datenschema der Anwendung erweitert werden: Es wird eine zusätzliche Datenbanktabelle benötigt, in der die Zuordnung von Benutzer zu OpenID festgehalten wird. Es empfiehlt sich, dass jeder Benutzer mehrere OpenIDs angeben kann, damit man sich auch nach einem Wechsel des Identity-Providers mit einer neuen OpenID einloggen kann. Die Tabelle speichert die ID des Benutzers und die dazugehörige OpenID:

CREATE TABLE openids (
	user_id int(11) NOT NULL,
	openid_url varchar(255) NOT NULL,
	KEY index_user_id (user_id),
	UNIQUE KEY unique_openid_url (openid_url)
);

Neben dem normalen Login mit Benutzername und Passwort wird ein weiteres Formular für die OpenID des Benutzers benötigt. Das OpenID-Textfeld wird üblicherweise mit dem OpenID-Logo gekennzeichnet und mit der HTML-ID „openid_identifier“ versehen, damit es gegebenenfalls von Plugins erkannt werden kann.

#openid_identifier {
	background: #FFFFFF url('/images/openid-icon-small.gif') no-repeat 0 50%;
	padding-left: 20px;
}

Das Loginformular zielt auf das Skript, das die Authentifizierungsanfrage einleitet. In der Beispielimplementierung ist dies die start-Action im OpenID-Controller.

Beim Speichern der OpenID-URL sollten Entwickler unbedingt darauf achten, die vom Identity-Provider zurückgelieferte OpenID in normalisierter Form abzuspeichern. Durch die Normalisierung werden die URLs so umgewandelt, dass sie immer einem bestimmten Schema entsprechen, dies erleichtert das Abgleichen beziehungsweise Auffinden von OpenIDs bei einem späteren Login. Beispielsweise wird die URL in Kleinschreibung umgewandelt und etwaige Slashes werden hinzugefügt oder entfernt [2]. Die meisten Bibliotheken verfügen über eine Normalisierungsfunktion beziehungsweise liefern die OpenID-URL bereits normalisiert zurück.