2015-08-19 14 views
13

Używam Spring Security OAuth2 i obecnie zaimplementowano typy grantów client_credentials i password. Zauważyłem, że klient ma zarówno zasięg, jak i autorytety. Czy ktoś może wyjaśnić, na czym polega różnica? Mówiąc dokładniej, używam JDBCTokenStore, a schemat bazy danych ma tabelę oauth_client_details.Wiosenny zakres oauth2 w stosunku do uprawnień (role)

Również

W tabeli oauth_client_details, nie jestem pewien, co się następujące pola są wykorzystywane do:

web_server_redirect_url, access_token_validity, refresh_token_validity

Niektóre wyjaśnienie byłoby bardzo pomocne i cenione .

+0

Mam to samo pytanie. [Prezentacja sprężyn znalezionych na slajdzie] (http://www.slideshare.net/SpringCentral/syer-oauth-model), w którym stwierdzono, że odróżniają one zakresy i autorytety: żetony użytkowników używają zakresów, tokenów klienta - organów. Ale nie mogę znaleźć żadnego powodu, aby to zrobić. Czy w końcu znalazłeś odpowiedź? – pls

+0

To, co odkryłem, to to, że nie jest zdefiniowany - to naprawdę zależy od Ciebie, kto wdraża serwer OAuth2. Poniższy post ma dobry przykład, do jakiego zakresu można użyć. – m1s4mike

+3

Możliwy duplikat [Różnica między zakresem i uprawnieniem w UAA] (https://stackoverflow.com/questions/35691051/difference-between-scope-and-authority-in-uaa) – EagleRainbow

Odpowiedz

9

zauważyłem klient ma zarówno zakres i władze

klient ma tylko zakres, ale możemy rozważyć/używać go jako organy (ról). Wynika to z tego, że specyfikacja OAuth nie wyjaśnia konkretnego zastosowania zakresu.

Weź pod uwagę, że użytkownik upoważnia twitter do publikowania tweetów użytkownika na Facebooku. W tym przypadku twitter będzie miał zasięg write_facebook_status. Chociaż użytkownik ma uprawnienia do zmiany profilu użytkownika, ale to nie znaczy, że Twitter może również zmienić profil użytkownika. Innymi słowy zasięg to uprawnienia/role klienta, a nie organy/role użytkownika.

web_server_redirect_url

zostanie to wykorzystane przez serwer autoryzacji przekierować żądanie do pierwotnego adresu URL lub zwrotnego (dotacja autoryzacja) po udanej autoryzacji.

access_token_validity

jest token_access czas ważności sekund. Ustaw na -1 lub 0 dla nieskończoności. Jeśli ustawisz go na 60, to po 1 minucie twój token_access będzie nieprawidłowy. Musisz zażądać nowego tokena, wykonując proces autoryzacji lub użyj refresh_token.

refresh_token_validity

to refresh_token czas ważności.

+0

"ponieważ specyfikacja OAuth nie wyjaśnia konkretnych użycie zakresu. ". Proszę wyjaśnij, dlaczego tak uważasz. Być może jakieś linki, które wyjaśnią to dalej? –

+0

@ AlikElzin-kilaka można go znaleźć tutaj https://tools.ietf.org/html/rfc6749#section-3.3 – MangEngkus