Z góry zaznaczam, że nie chodzi mi o wdrożenie popularnego openID a stworzenie własnego mechanizmu logowania.
Zakładając, że mam kilka aplikacji które mogą, lecz nie muszą być ze sobą powiązane, to jak rozwiązać logowanie do nich z jednego panelu.

Osobna aplikacja ten "mójopenID" instalowany na serwerze + osobne kontrolery dla aplikacji które by z niej korzystały, ale jak to rozwiązać w praktyce. Skrypt "mójopenID" pobierałby dane z aplikacji jak login i hasło do siebie, czy na bazie informacji o aplikacji w jakiej działa, sprawdzałby login i hasło u niej?

Bardziej logiczne wydaje się, aby aplikacja odpytywała serwer główny i tam były zapisywane wszystkie informacje. Jeśli każda aplikacja trzymała by dane u siebie to później mogą się pojawić problemy z synchronizacją w razie gdyby np. użytkownik zmienił hasło.

Najprostszy system OpenId jaki mi przychodzi na myśl i w miarę bezpieczny to taki któy działa w ten sposób (najprościej jak się da):

Serwis, który chcę logować użytkownika po openId tworzy link do serwisu z openid i podaje w nim link zwrotny do siebie. User wchodzi w link i jest już na serwisie openid. Tutaj sprawdzane jest czy użytkownik jest zalogowany w serwisie openid czy nie - jesli nie to musi się zalogować. Jeśli jest (już) zalogowany to następuję przekierowanie na wskazany wcześniej adres serwisu zwykłego z odpowiednimi parametrami takimi jak (w minimalnej formie) email. Po tym emailu serwis zwykły sprawdza czy ma już takiego użytkownika i tworzy go jeśli nie. Dodatkowo loguje go na utworzone już dla nie go konto. Tyle.

Taka jest główna idea, do której trzeba trochę objaśnień:
- komunikacja po stronie serwis <=> serwis openId musi być jakoś zabezpieczona (nie może to byś adres zwrotny typu "?email=aaa@xxx.yy" bo każdy może sobie na takowy wejść). Przede wszystkim w linku do serwisu openid musisz wygenerować jakiś hash/zaszyfrować coś - serwis openid musi to jakoś przerobić swoim algorytmem i dodać do adresu zwrotnego. W ten sposób masz pewność że ten request jest odpowiedzią na poprzedni - klasy i hashowanie obmyśl sam Dodaj do tego jeszcze sprawdzanie referera.
- jeśli gość jest zalogowany w serwisie openid to odrazu możesz go po wejściu w link przekierować na link zwrotny - możesz też zrobić akceptację - to znaczy sprawdzasz w serwisie openid skąd idzie request i dla jakiego usera i pytasz czy user jest pewny że chcę się tak uwierzytelniać - możesz to zapisać jako parę user+serwis aby potem o to nie pytać.
- parametry przesyłane zwrotnie z serwisu openid nie mogą zawierać hasła użytkownika. W serwisie zwykłym user powinien mieć swoje własne hasło (moze być wygenerowane a po pierwszym logowaniu via openid wysłane mailem do niego) - jedyny tak naprawdę parametr jaki musi być wysłany to unikalny email/login.

Tyle Robisz jedną klasę dla serwerów zewnętrznych i obsługę serwera openid i śmiga.

Zapomniałem dodać, że ten "openID" byłby instalowany na tym samym serwerze na którym działają aplikacje, ponieważ niektóre z nich nie mają dostępu na zewnątrz.

@Sephirus - czyli z aplikacji A, wchodzę w zaloguj po czym przekierowuje mnie na adres z openID i tam wpisuje login z hasłem, po zalogowaniu (ale specjalnym kontem jaki ma openID, czy danimi z aplikacji?) i poprawnej weryfikacji odsyła mnie z powrotem? Tak, logiczne... ale... właśnie... Konto openID, musi być nowe czy zrobić to na zasadzie logowania na bazie danych z aplikacji A, tylko po weryfikacji klucza/hashu/czegokolwiek? I czy gdzieś te dane trzymać, czy "openID" ma mieć je u siebie...

Sama autoryzacja openID była już omawiana (może nie openID ale cel jest podobny):
http://forum.php.pl/index.php?showtopic=221467
Temat: index.php/style emoticons/default/Identyfikacja uzytkownikow w aplikacjach sieciowych

Załóżmy że serwisy korzystające z openid to A B i C a serwis trzymający openid to O:

W A,B lub C masz linki do serwisu O typu

http://o.com/?akcja=pobierz_dane&hash=...om/openidlogin/

na taki link klika user i zostaje przekierowany - jest teraz na serwisie o.com. Tutaj serwis O sprawdza czy user jest na nim zalogowany - jeśli nie jest to pokazuje się form logowania (logowania do systemu O) po zalogowaniu, lub jak user był zalogowany wcześniej następuje przekierowanie na adres:

http://a.com/openidlogin/?hash=funkcja(123...s_email@xxx.yyy

Na tej stronie system A sprawdza czy hash został poprawnie przetworzony i czy zgadza się referer (o.com) a następnie sprawdza czy ma już konto dla podanego adresu e-mail. Jeśli konto jest następuję logowanie i przekierowanie do głównej strony a.com. Jeśli nie ma konta to tworzone jest konto dla tego adresu, generowane jakieś hasło i wysyłany mail z tym hasłem na ten adres (tak by user miał możliwość zalogowania się w tradycyjny sposó. Następnie tak samo jest autologowanie i redir do głównej a.com.

sama idea hashy polega na wygenerowaniu jakiegoś do linku na a.com. Hash ten jest przetwarzany jakąś funkcją na o.com i odsyłany - zarówno a.com jak i o.com muszą znać algorytmu generowania i sprawdzania takiego hasha.



Konto openid na serwerze o.com musi być utworzone na samym początku najlepiej. Tam powinny być przechowywane główne dane usera. Po całej procedurze logowania za pośrednictwem o.com na serwisie a.com to Ty decydujesz jakie dane ma wysłać o.com do serwisu a.com - te dane mogą być wtedy zapisane także w a.com. Przykład z życia wzięty:

Jest strona, możesz się na niej zalogować poprzez Google. Klikasz na link, jesteś zalogowany w google, zgadzasz się i wtedy strona ta dostaje jakiś komplet info o Tobie. Google wysyła AFAIK imię, nazwisko, email i coś tam jeszcze. ALE NIGDY HASEŁ itp.

Cała zasada systemów typu openid polega na tzw. poręczeniu. Oznacza to że serwis O bierzę na siebie pełną odpowiedzialność za tożsamość użytkownika. Wchodząc na O logujesz się (tylko ty znasz dane logowania). Serwis A prosi O tylko o to by powiedział jaki user się zalogował - wraz z systemem hashy i tym podobnych mechanizmów może ufać serwisowi O

@buliq - te linki niewiele wnoszą do tematu, np. oauth nie jest w standardzie.
@Sephirus - dzięki, muszę to sprawdzić "na żywo" ;)