OAuth 2: oddzielenie serwera zasobów i serwera autoryzacji

Question

Specyfikacja OAuth 2 prowadzi mnie do przekonania, że ​​"serwer zasobów" i "serwer autoryzacji" niekoniecznie muszą być tą samą aplikacją, ale staram się wymyślić, jak to jest faktycznie wdrażany w praktyce.

Jako przykład załóżmy, że istnieją następujące aplikacje:

• zasobów serwera
• serwer autoryzacji
• web frontend
• stronę trzecią app klient

Scenariusz nr 1: Logowanie do interfejsu WWW

• użytkownik przesyła formularz logowania
• Web App posty poświadczeń AUTH serwera (grant_type = hasło) i otrzymuje access_token
• sklepów Web App access_token w sesji
• po każdym kolejnym życzenie:
  • GET zasobu (ów) z serwera zasobów (w/access_token w nagłówku Authorization) i uczynić go w interfejsie WWW
  • jeśli otrzymujemy 401, a następnie zalogować się użytkownikowi (usunąć access_token z sesji)

Scenariusz nr 2: Autoryzacja aplikacji innych firm

• użytkownik zażąda autoryzacji z serwisu auth
• pozwalają/zaprzeczyć formularz jest wyświetlany
• użytkownik zostaje przekierowany z powrotem do aplikacji klienckiej z upoważnienia obecny kod
• aplikacja kliencka kodu POST do autoryzacji usługi (grant_type = kod autoryzacji) i otrzymuje kod dostępu
• klient otrzymuje środki z zasobów serwera mijania (w/Auth nagłówku)

Część mam kłopoty ze zrozumieniem jest jak do uwierzytelnienia użytkownika przed pokazując umożliwić/zaprzeczyć postać w scenariuszu 2 #. Użytkownik może być zalogowany do głównej aplikacji internetowej, ale usługa autoryzacji nie ma o tym pojęcia i powinna jakoś ponownie uwierzytelnić użytkownika. Czy usługa autoryzacji musi również obsługiwać logowanie/sesje?

Zastanawiam się, czy może to więcej sensu dla aplikacji internetowych, który jest odpowiedzialny za wykazujące umożliwić/zaprzeczyć formę z dwóch powodów:

1. to zachowuje wszystkie UI w jednej aplikacji
2. nie zmusi użytkownika, aby ponownie swoje poświadczenia, jeśli są one już zalogowany do aplikacji internetowej

Oto jeden z możliwych alternatyw dla scenariusza # 2:

• użytkownik zażąda autoryzacji z aplikacji internetowej
• pozwalają/zaprzeczyć formularz jest wyświetlany
• Web App postów do auth serwera tworząc nową dotację, kod autoryzacji jest zwracana
• aplikację internetową przekierowuje do aplikacji klienckiej z kodem autoryzacji niniejszego
• klient kod POST aplikacji do serwisu auth i otrzymuje access_token

Jaki jest najlepszy sposób, aby sobie z tym poradzić? Wszelkie ogólne uwagi, porady itp. Byłyby niesamowite!

Dzięki

Answer 1

alternatywny scenariusz jest chyba to, co chcesz iść z: jeśli naprawdę naprawdę chcesz oddzielić wypływa, można spróbować czegoś takiego: zezwolenie

1. żądania użytkownika z auth usługa w imieniu usługi z grant_type = kod
2. usługa auth świadczy o tym, że użytkownik nie jest zalogowany: przekierowuje do aplikacji internetowej z parametrem żądania, prosząc serwer internetowy o odesłanie użytkownika.
3. aplikacja internetowa przechowuje parametr żądania, a następnie pyta o nazwę użytkownika/hasło
4. aplikacja internetowa Poświadczenia POST dla serwera auth (grant_type = hasło) i otrzymuje hasło dostępu.
5. sklepy Web App access_token w sesji
6. aplikacja internetowa generuje podpisaną żeton uchwycenie identyfikator użytkownika i przekierowuje z powrotem do serwisu auth z podpisanym tokena jako żądanie parametru
7. usługa auth analizuje podpisanej żeton, wyciągi użytkownikowi id, wyświetlacze pozwalają/zaprzeczyć formularz
8. użytkownik zostaje przekierowany z powrotem do aplikacji klienckiej z kodem autoryzacji niniejszego
aplikacja
9. klient kod postów do dopuszczonego usługę (grant_type = kod_autoryz) i otrzymuje access_token
10. klient otrzymuje środki z zasobów serwera przekazywanie (w/Auth nagłówek)

Answer 2

OAauth2 ramowe docs: https://tools.ietf.org/html/rfc6749

(A) Klient żąda tokenu dostępu przez uwierzytelnianie z serwerem autoryzacji i prezentuje udzielić zezwolenia.

(B) Serwer autoryzacji uwierzytelnia klienta i potwierdza przyznanie autoryzacji , a jeśli jest prawidłowy, wystawia token dostępu i token odświeżania.

(C) Klient wysyła chronione żądanie zasobów do serwera zasobów , prezentując token dostępu.

(D) Serwer zasobów sprawdza poprawność tokena dostępu, a jeśli jest prawidłowy, to obsługuje żądanie .

(E) Kroki (C) i (D) należy powtarzać do momentu wygaśnięcia tokena dostępu. Jeśli klient wie, że token dostępu wygasł, przechodzi do kroku (G); w przeciwnym razie tworzy inne chronione żądanie zasobów.

(F) Ponieważ token dostępu jest nieprawidłowy, serwer zasobów zwraca nieprawidłowy błąd tokena.

(G) Klient żąda nowego tokenu dostępu, uwierzytelniając się pod numerem na serwerze autoryzacji i wyświetlając token odświeżania. Wymagania dotyczące uwierzytelniania klienta są oparte na typie klienta oraz na zasadach serwera autoryzacji.

(H) Serwer autoryzacji uwierzytelnia klienta i zatwierdza token odświeżania, a jeśli jest prawidłowy, wydaje nowy token dostępu (i, opcjonalnie, , nowy token odświeżania).