OpenID Connect

Interfejsów API Google OAuth 2.0 można używać zarówno do uwierzytelniania, jak i autoryzacji. W tym dokumencie opisujemy naszą implementację protokołu OAuth 2.0 do uwierzytelniania, która jest zgodna ze specyfikacją OpenID Connect i ma certyfikat OpenID. Dokumentacja dostępna w artykule Używanie protokołu OAuth 2.0 na potrzeby dostępu do interfejsów API Google dotyczy również tej usługi. Jeśli chcesz poznać ten protokół w sposób interaktywny, zalecamy skorzystanie z Google OAuth 2.0 Playground. Aby uzyskać pomoc na stronie Stack Overflow, oznacz swoje pytania tagiem „google-oauth”.

Konfigurowanie protokołu OAuth 2.0

Zanim Twoja aplikacja będzie mogła używać systemu uwierzytelniania Google OAuth 2.0 do logowania użytkowników, musisz skonfigurować projekt w konsoli Google Cloud, aby uzyskać dane logowania OAuth 2.0, ustawić identyfikator URI przekierowania i (opcjonalnie) dostosować informacje o marce, które użytkownicy widzą na ekranie zgody użytkownika. Możesz też użyć konsoli Cloud, aby utworzyć konto usługi, włączyć płatności, skonfigurować filtrowanie i wykonać inne zadania. Więcej informacji znajdziesz w Pomocy konsoli Google Cloud.

Uzyskiwanie danych logowania OAuth 2.0

Aby uwierzytelniać użytkowników i uzyskiwać dostęp do interfejsów API Google, potrzebujesz danych logowania OAuth 2.0, w tym identyfikatora klienta i tajnego klucza klienta.

Aby wyświetlić identyfikator klienta i tajny klucz klienta dla danych logowania OAuth 2.0, kliknij ten tekst: Wybierz dane logowania. W wyświetlonym oknie wybierz projekt i dane logowania, a następnie kliknij Wyświetl.

Możesz też wyświetlić identyfikator i tajny klucz klienta na stronie Klienci w konsoli Cloud:

1. Otwórz stronę Klienci.
2. Kliknij nazwę klienta lub ikonę edycji (create). Identyfikator klienta i tajny klucz znajdują się u góry strony.

Ustawianie identyfikatora URI przekierowania

Identyfikator URI przekierowania ustawiony w konsoli Cloud określa, gdzie Google wysyła odpowiedzi na żądania uwierzytelniania.

Aby utworzyć, wyświetlić lub edytować identyfikatory URI przekierowania dla danych logowania OAuth 2.0:

1. Otwórz stronę Klienci.
2. Kliknij klienta.
3. Wyświetl lub edytuj identyfikatory URI przekierowania.

Jeśli na stronie Klienty nie ma żadnego klienta, Twój projekt nie ma danych logowania OAuth. Aby go utworzyć, kliknij Utwórz klienta.

Dostosowywanie ekranu zgody użytkownika

W przypadku użytkowników proces uwierzytelniania OAuth 2.0 obejmuje ekran zgody, który opisuje informacje udostępniane przez użytkownika i obowiązujące warunki. Na przykład gdy użytkownik się zaloguje, może zostać poproszony o przyznanie aplikacji dostępu do jego adresu e-mail i podstawowych informacji o koncie. Dostęp do tych informacji możesz uzyskać za pomocą parametru scope, który aplikacja uwzględnia w żądaniu uwierzytelnienia. Możesz też używać zakresów, aby prosić o dostęp do innych interfejsów API Google.

Ekran zgody użytkownika zawiera też informacje o marce, takie jak nazwa produktu, logo i adres URL strony głównej. Informacje o marce możesz kontrolować w konsoli Cloud.

Aby włączyć ekran zgody w projekcie:

1. Otwórz stronę Marka w konsoli Google Cloud.
2. Jeśli pojawi się taka prośba, wybierz projekt lub utwórz nowy.
3. Wypełnij formularz i kliknij Zapisz.

Poniższe okno z prośbą o zgodę na przetwarzanie danych osobowych pokazuje, co zobaczy użytkownik, gdy w żądaniu występuje kombinacja zakresów OAuth 2.0 i Dysku Google. (To ogólne okno zostało wygenerowane za pomocą Google OAuth 2.0 Playground, więc nie zawiera informacji o marce, które zostałyby ustawione w konsoli Cloud).

Uzyskiwanie dostępu do usługi

Google i inne firmy udostępniają biblioteki, które mogą pomóc w obsłudze wielu szczegółów implementacji związanych z uwierzytelnianiem użytkowników i uzyskiwaniem dostępu do interfejsów API Google. Przykłady obejmują Google Identity Services i biblioteki klienta Google, które są dostępne na różnych platformach.

Jeśli zdecydujesz się nie korzystać z biblioteki, postępuj zgodnie z instrukcjami podanymi w pozostałej części tego dokumentu, która opisuje przepływy żądań HTTP stanowiące podstawę dostępnych bibliotek.

Uwierzytelnianie użytkownika

Uwierzytelnianie użytkownika obejmuje uzyskanie tokena identyfikacji i jego weryfikację. Tokeny identyfikacji to standardowa funkcja OpenID Connect, która umożliwia udostępnianie asercji tożsamości w internecie.

Najpopularniejsze metody uwierzytelniania użytkownika i uzyskiwania tokena identyfikacji to przepływ „serwerowy” i „niejawny”. Przepływ po stronie serwera umożliwia serwerowi backendu aplikacji zweryfikowanie tożsamości osoby korzystającej z przeglądarki lub urządzenia mobilnego. Przepływ niejawny jest używany, gdy aplikacja po stronie klienta (zwykle aplikacja JavaScript działająca w przeglądarce) musi uzyskać dostęp do interfejsów API bezpośrednio, a nie za pomocą serwera backendu.

Z tego dokumentu dowiesz się, jak przeprowadzić proces uwierzytelniania użytkownika po stronie serwera. Przepływ niejawny jest znacznie bardziej skomplikowany ze względu na zagrożenia bezpieczeństwa związane z obsługą i używaniem tokenów po stronie klienta. Jeśli musisz wdrożyć przepływ niejawny, zdecydowanie zalecamy korzystanie z Google Identity Services.

Przepływ po stronie serwera

Pamiętaj, aby skonfigurować aplikację w konsoli Cloud, aby mogła używać tych protokołów i uwierzytelniać użytkowników. Gdy użytkownik próbuje zalogować się przez Google, musisz:

1. Tworzenie tokena stanu chroniącego przed fałszowaniem
2. Wysyłanie do Google prośby o uwierzytelnienie
3. Potwierdzanie tokena stanu zapobiegającego fałszowaniu
4. Wymiana code na token dostępu i token identyfikacji
5. Uzyskiwanie informacji o użytkowniku z tokena identyfikatora
6. Uwierzytelnianie użytkownika

1. Tworzenie tokena stanu chroniącego przed fałszowaniem

Musisz chronić bezpieczeństwo użytkowników, zapobiegając atakom polegającym na fałszowaniu żądań. Pierwszym krokiem jest utworzenie unikalnego tokena sesji, który przechowuje stan między aplikacją a klientem użytkownika. Później dopasowujesz ten unikalny token sesji do odpowiedzi uwierzytelniania zwróconej przez usługę logowania Google OAuth, aby sprawdzić, czy żądanie pochodzi od użytkownika, a nie od złośliwego atakującego. Te tokeny są często nazywane tokenami fałszowania żądań z innej witryny (CSRF).

Dobrym wyborem w przypadku tokena stanu jest ciąg około 30 znaków utworzony za pomocą wysokiej jakości generatora liczb losowych. Innym jest skrót generowany przez podpisanie niektórych zmiennych stanu sesji kluczem, który jest przechowywany w tajemnicy w Twoim backendzie.

Poniższy kod pokazuje, jak wygenerować unikalne tokeny sesji.

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
$state = bin2hex(random_bytes(128/8));
$app['session']->set('state', $state);
// Set the client ID, token state, and application name in the HTML while
// serving it.
return $app['twig']->render('index.html', array(
    'CLIENT_ID' => CLIENT_ID,
    'STATE' => $state,
    'APPLICATION_NAME' => APPLICATION_NAME
));

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
String state = new BigInteger(130, new SecureRandom()).toString(32);
request.session().attribute("state", state);
// Read index.html into memory, and set the client ID,
// token state, and application name in the HTML before serving it.
return new Scanner(new File("index.html"), "UTF-8")
    .useDelimiter("\\A").next()
    .replaceAll("[{]{2}\\s*CLIENT_ID\\s*[}]{2}", CLIENT_ID)
    .replaceAll("[{]{2}\\s*STATE\\s*[}]{2}", state)
    .replaceAll("[{]{2}\\s*APPLICATION_NAME\\s*[}]{2}",
    APPLICATION_NAME);

# Create a state token to prevent request forgery.
# Store it in the session for later validation.
state = hashlib.sha256(os.urandom(1024)).hexdigest()
session['state'] = state
# Set the client ID, token state, and application name in the HTML while
# serving it.
response = make_response(
    render_template('index.html',
                    CLIENT_ID=CLIENT_ID,
                    STATE=state,
                    APPLICATION_NAME=APPLICATION_NAME))

2. Wysyłanie żądania uwierzytelnienia do Google

Następnym krokiem jest utworzenie żądania HTTPS GET z odpowiednimi parametrami identyfikatora URI. Zwróć uwagę, że na wszystkich etapach tego procesu używany jest protokół HTTPS, a nie HTTP. Połączenia HTTP są odrzucane. Podstawowy identyfikator URI należy pobrać z dokumentu opisującego, używając wartości metadanych authorization_endpoint. W poniższym omówieniu zakładamy, że podstawowy identyfikator URI to https://accounts.google.com/o/oauth2/v2/auth.

W przypadku podstawowego żądania określ te parametry:

• client_id, który uzyskasz na stronie Klienci w konsoli Cloud.
• response_type, który w podstawowym żądaniu przepływu kodu autoryzacji powinien mieć wartość code. (więcej informacji: response_type).
• scope, który w podstawowym żądaniu powinien mieć wartość openid email. (więcej informacji: scope).
• redirect_uri powinien być punktem końcowym HTTP na Twoim serwerze, który będzie otrzymywać odpowiedź od Google. Wartość musi dokładnie odpowiadać jednemu z autoryzowanych identyfikatorów URI przekierowania dla klienta OAuth 2.0, który został skonfigurowany na stronie Dane logowania w konsoli Cloud. Jeśli ta wartość nie jest zgodna z autoryzowanym identyfikatorem URI, żądanie nie powiedzie się i wystąpi błąd redirect_uri_mismatch.
• state powinien zawierać wartość unikalnego tokena sesji zapobiegającego fałszowaniu, a także wszelkie inne informacje potrzebne do przywrócenia kontekstu, gdy użytkownik wróci do aplikacji, np. początkowy adres URL. (więcej informacji: state).
• nonce to losowa wartość wygenerowana przez aplikację, która umożliwia ochronę przed powtórzeniem, gdy jest obecna.
• login_hint może być adresem e-mail użytkownika lub ciągiem znaków sub, który odpowiada identyfikatorowi Google użytkownika. Jeśli nie podasz parametru login_hint, a użytkownik jest zalogowany, ekran zgody będzie zawierał prośbę o zgodę na udostępnienie Twojej aplikacji adresu e-mail użytkownika. (Więcej informacji znajdziesz na stronie login_hint).
• Użyj parametru hd, aby zoptymalizować proces OpenID Connect dla użytkowników określonej domeny powiązanej z organizacją Google Workspace lub Cloud (więcej informacji znajdziesz na stronie hd).

Oto przykład pełnego identyfikatora URI uwierzytelniania OpenID Connect z podziałami wierszy i spacjami, które ułatwiają czytanie:

https://accounts.google.com/o/oauth2/v2/auth?
 response_type=code&
 client_id=424911365001.apps.googleusercontent.com&
 scope=openid%20email&
 redirect_uri=https%3A//developers.google.com/oauthplayground&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2-login-demo.example.com%2FmyHome&
 login_hint=jsmith@example.com&
 nonce=0394852-3190485-2490358&
 hd=example.com

Użytkownicy muszą wyrazić zgodę, jeśli aplikacja prosi o nowe informacje o nich lub o dostęp do konta, którego wcześniej nie zatwierdzili.

3. Potwierdź token stanu zapobiegający fałszowaniu

Odpowiedź jest wysyłana do redirect_uri określonego w żądaniu. Wszystkie odpowiedzi są zwracane w ciągu zapytania:

https://developers.google.com/oauthplayground?state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foa2cb.example.com%2FmyHome&code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&scope=openid%20email%20https://www.googleapis.com/auth/userinfo.email

Zgodnie ze specyfikacją RFC 6749 klienci MUSZĄ ignorować nierozpoznane parametry odpowiedzi. Na serwerze musisz potwierdzić, że parametr state otrzymany od Google jest zgodny z tokenem sesji utworzonym w kroku 1. Ta weryfikacja w obie strony pomaga sprawdzić, czy żądanie wysyła użytkownik, a nie złośliwy skrypt.

Poniższy kod pokazuje, jak potwierdzić tokeny sesji utworzone w kroku 1:

// Ensure that there is no request forgery going on, and that the user
// sending us this connect request is the user that was supposed to.
if ($request->get('state') != ($app['session']->get('state'))) {
  return new Response('Invalid state parameter', 401);
}

// Ensure that there is no request forgery going on, and that the user
// sending us this connect request is the user that was supposed to.
if (!request.queryParams("state").equals(
    request.session().attribute("state"))) {
  response.status(401);
  return GSON.toJson("Invalid state parameter.");
}

# Ensure that the request is not a forgery and that the user sending
# this connect request is the expected user.
if request.args.get('state', '') != session['state']:
  response = make_response(json.dumps('Invalid state parameter.'), 401)
  response.headers['Content-Type'] = 'application/json'
  return response

4. Wymień code na token dostępu i token identyfikatora

Odpowiedź zawiera parametr code, czyli jednorazowy kod autoryzacji, który serwer może wymienić na token dostępu i token identyfikacji. Serwer dokonuje tej wymiany, wysyłając żądanie HTTPS POST. Żądanie POST jest wysyłane do punktu końcowego tokena, który należy pobrać z dokumentu opisującego za pomocą wartości metadanych token_endpoint. W poniższym omówieniu zakładamy, że punkt końcowy to https://oauth2.googleapis.com/token. Żądanie musi zawierać te parametry w treści POST:

Rzeczywiste żądanie może wyglądać tak:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your-client-id&
client_secret=your-client-secret&
redirect_uri=https%3A//developers.google.com/oauthplayground&
grant_type=authorization_code

Odpowiedź na to żądanie informująca o powodzeniu zawiera te pola w tablicy JSON:

5. Uzyskiwanie informacji o użytkowniku z tokena identyfikacji

Token identyfikacji to JWT (token sieciowy JSON), czyli kryptograficznie podpisany obiekt JSON zakodowany w formacie Base64. Zwykle przed użyciem tokena identyfikacji należy go zweryfikować, ale ponieważ komunikujesz się bezpośrednio z Google przez kanał HTTPS bez pośredników i używasz tajnego klucza klienta do uwierzytelniania się w Google, możesz mieć pewność, że otrzymany token naprawdę pochodzi od Google i jest prawidłowy. Jeśli serwer przekazuje token identyfikacji do innych komponentów aplikacji, bardzo ważne jest, aby te komponenty zweryfikowały token przed jego użyciem.

Większość bibliotek interfejsu API łączy weryfikację z dekodowaniem wartości zakodowanych w formacie base64url i analizowaniem kodu JSON, więc prawdopodobnie i tak zweryfikujesz token, gdy uzyskasz dostęp do oświadczeń w tokenie identyfikacji.

ładunek tokena identyfikacji,

Token identyfikacji to obiekt JSON zawierający zestaw par nazwa/wartość. Oto przykład sformatowany pod kątem czytelności:

{
  "iss": "https://accounts.google.com",
  "azp": "1234987819200.apps.googleusercontent.com",
  "aud": "1234987819200.apps.googleusercontent.com",
  "sub": "10769150350006150715113082367",
  "at_hash": "HK6E_P6Dh8Y93mRNtsDB1Q",
  "hd": "example.com",
  "email": "jsmith@example.com",
  "email_verified": "true",
  "iat": 1353601026,
  "exp": 1353604926,
  "nonce": "0394852-3190485-2490358"
}

Tokeny identyfikatora Google mogą zawierać te pola (nazywane twierdzeniami):

6. Uwierzytelnianie użytkownika

Po uzyskaniu informacji o użytkowniku z tokena identyfikacji należy wysłać zapytanie do bazy danych użytkowników aplikacji. Jeśli użytkownik już istnieje w Twojej bazie danych, rozpocznij dla niego sesję aplikacji, jeśli wszystkie wymagania dotyczące logowania są spełnione przez odpowiedź interfejsu API Google.

Jeśli użytkownika nie ma w Twojej bazie danych, przekieruj go do procesu rejestracji nowego użytkownika. Możesz automatycznie zarejestrować użytkownika na podstawie informacji otrzymanych od Google lub przynajmniej wstępnie wypełnić wiele pól wymaganych w formularzu rejestracyjnym. Oprócz informacji zawartych w tokenie identyfikacji możesz uzyskać dodatkowe informacje o profilu użytkownika w naszych punktach końcowych profilu użytkownika.

Tematy zaawansowane

W kolejnych sekcjach znajdziesz bardziej szczegółowe informacje o interfejsie Google OAuth 2.0 API. Te informacje są przeznaczone dla deweloperów, którzy mają zaawansowane wymagania dotyczące uwierzytelniania i autoryzacji.

Dostęp do innych interfejsów API Google

Jedną z zalet korzystania z protokołu OAuth 2.0 do uwierzytelniania jest to, że aplikacja może uzyskać uprawnienia do korzystania z innych interfejsów API Google w imieniu użytkownika (np. YouTube, Dysk Google, Kalendarz lub Kontakty) w tym samym czasie, gdy uwierzytelniasz użytkownika. Aby to zrobić, uwzględnij inne potrzebne zakresy w żądaniu uwierzytelnienia, które wysyłasz do Google. Aby na przykład dodać grupę wiekową użytkownika do żądania uwierzytelnienia, przekaż parametr zakresu openid email https://www.googleapis.com/auth/profile.agerange.read. Użytkownik zobaczy odpowiedni komunikat na ekranie zgody. Token dostępu, który otrzymasz od Google, umożliwi Twojej aplikacji dostęp do wszystkich interfejsów API związanych z zakresami dostępu, o które prosisz i które zostały Ci przyznane.

Tokeny odświeżania

W żądaniu dostępu do interfejsu API możesz poprosić o zwrócenie tokena odświeżania podczas wymiany code. Token odświeżania zapewnia aplikacji stały dostęp do interfejsów API Google, gdy użytkownik nie korzysta z aplikacji. Aby poprosić o token odświeżania, w żądaniu uwierzytelnienia ustaw parametr access_type na offline.

Uwagi:

• Pamiętaj, aby bezpiecznie i trwale przechowywać token odświeżania, ponieważ możesz go uzyskać tylko podczas pierwszego wykonania procesu wymiany kodu.
• Istnieją limity liczby wydawanych tokenów odświeżania: jeden limit na kombinację klienta i użytkownika oraz inny na użytkownika we wszystkich klientach. Jeśli aplikacja żąda zbyt wielu tokenów odświeżania, może przekroczyć te limity, co spowoduje, że starsze tokeny odświeżania przestaną działać.

Więcej informacji znajdziesz w artykule Refreshing an access token (offline access) (Odświeżanie tokena dostępu – dostęp offline).

Prośba o ponowne wyrażenie zgody

Możesz poprosić użytkownika o ponowne autoryzowanie aplikacji, ustawiając parametr prompt na consent w żądaniu uwierzytelnienia. Gdy parametr prompt=consent jest uwzględniony, ekran zgody wyświetla się za każdym razem, gdy aplikacja prosi o autoryzację zakresów dostępu, nawet jeśli wszystkie zakresy zostały wcześniej przyznane projektowi interfejsów API Google. Z tego powodu uwzględniaj prompt=consent tylko wtedy, gdy jest to konieczne.

Więcej informacji o parametrze prompt znajdziesz w sekcji prompt w tabeli Parametry identyfikatora URI uwierzytelniania.

Parametry identyfikatora URI uwierzytelniania

W tabeli poniżej znajdziesz bardziej szczegółowe opisy parametrów akceptowanych przez interfejs API uwierzytelniania OAuth 2.0 od Google.

Weryfikowanie tokena identyfikacji

Musisz zweryfikować wszystkie tokeny identyfikacji na serwerze, chyba że wiesz, że pochodzą bezpośrednio od Google. Na przykład serwer musi zweryfikować autentyczność wszystkich tokenów identyfikacji, które otrzymuje z aplikacji klienckich.

Oto typowe sytuacje, w których możesz wysyłać tokeny identyfikacji na serwer:

• wysyłanie tokenów identyfikacji z żądaniami, które wymagają uwierzytelnienia; Tokeny identyfikacji informują o konkretnym użytkowniku, który wysyła żądanie, oraz o tym, dla którego klienta token identyfikacji został przyznany.

Tokeny identyfikacji są poufne i mogą zostać wykorzystane w niewłaściwy sposób, jeśli zostaną przechwycone. Musisz zadbać o bezpieczne przetwarzanie tych tokenów, przesyłając je tylko przez HTTPS i tylko przy użyciu danych POST lub w nagłówkach żądań. Jeśli przechowujesz tokeny identyfikacji na serwerze, musisz też zadbać o ich bezpieczeństwo.

Jedną z zalet tokenów identyfikacji jest to, że można je przekazywać między różnymi komponentami aplikacji. Te komponenty mogą używać tokena identyfikacji jako uproszczonego mechanizmu uwierzytelniania aplikacji i użytkownika. Zanim jednak użyjesz informacji zawartych w tokenie identyfikacji lub uznasz je za potwierdzenie, że użytkownik został uwierzytelniony, musisz je zweryfikować.

Weryfikacja tokena identyfikacji wymaga wykonania kilku kroków:

1. Sprawdź, czy token identyfikacji jest prawidłowo podpisany przez wydawcę. Tokeny wydane przez Google są podpisywane za pomocą jednego z certyfikatów znalezionych pod identyfikatorem URI określonym w wartości metadanych jwks_uri w dokumencie opisującym.
2. Sprawdź, czy wartość oświadczenia iss w tokenie identyfikacji jest równa https://accounts.google.com lub accounts.google.com.
3. Sprawdź, czy wartość oświadczenia aud w tokenie identyfikacji jest równa identyfikatorowi klienta aplikacji.
4. Sprawdź, czy nie upłynął czas wygaśnięcia (deklaracja exp) tokena identyfikacji.
5. Jeśli w żądaniu podano wartość parametru hd, sprawdź, czy token identyfikacji zawiera oświadczenie hd, które pasuje do akceptowanej domeny powiązanej z organizacją Google Cloud.

Kroki od 2 do 5 obejmują tylko porównania ciągów znaków i dat, które są dość proste, więc nie będziemy ich tutaj szczegółowo opisywać.

Pierwszy krok jest bardziej złożony i obejmuje sprawdzanie podpisu kryptograficznego. W celach debugowania możesz użyć punktu końcowego tokeninfo Google, aby porównać go z przetwarzaniem lokalnym zaimplementowanym na serwerze lub urządzeniu. Załóżmy, że wartość tokena identyfikacji to XYZ123. Następnie wyłuskasz identyfikator URI: https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123. Jeśli podpis tokena jest prawidłowy, odpowiedzią będzie ładunek JWT w postaci zdekodowanego obiektu JSON.

Punkt końcowy tokeninfo jest przydatny do debugowania, ale w celach produkcyjnych pobierz klucze publiczne Google z punktu końcowego kluczy i przeprowadź weryfikację lokalnie. Identyfikator URI kluczy należy pobrać z dokumentu opisującego, używając wartości metadanych jwks_uri. Żądania wysyłane do punktu końcowego debugowania mogą być ograniczane lub w inny sposób podlegać sporadycznym błędom.

Google rzadko zmienia swoje klucze publiczne, więc możesz je przechowywać w pamięci podręcznej, korzystając z dyrektyw pamięci podręcznej odpowiedzi HTTP. W większości przypadków lokalna weryfikacja będzie znacznie wydajniejsza niż użycie punktu końcowego tokeninfo. Ta weryfikacja wymaga pobrania i przeanalizowania certyfikatów oraz wykonania odpowiednich wywołań kryptograficznych w celu sprawdzenia podpisu. Na szczęście dostępne są dobrze przetestowane biblioteki w wielu językach, które umożliwiają wykonanie tego zadania (zobacz jwt.io).

Uzyskiwanie informacji o profilu użytkownika

Aby uzyskać dodatkowe informacje o profilu użytkownika, możesz użyć tokena dostępu (który aplikacja otrzymuje podczas procesu uwierzytelniania) i standardu OpenID Connect:

1. Aby zachować zgodność z OpenID, musisz uwzględnić wartości zakresu openid profile w żądaniu uwierzytelniania.

   Jeśli chcesz, aby adres e-mail użytkownika był uwzględniany, możesz określić dodatkową wartość zakresu email. Aby określić zarówno profile, jak i email, możesz uwzględnić w identyfikatorze URI żądania uwierzytelnienia ten parametr:

   scope=openid%20profile%20email
   

2. Dodaj token dostępu do nagłówka autoryzacji i wyślij żądanie HTTPS GET do punktu końcowego userinfo, który należy pobrać z dokumentu opisującego, używając wartości metadanych userinfo_endpoint. Odpowiedź userinfo zawiera informacje o użytkowniku, zgodnie z opisem w OpenID Connect Standard Claims i wartością metadanych claims_supported w dokumencie Discovery. Użytkownicy lub ich organizacje mogą zdecydować, czy chcą podać lub ukryć określone pola, więc możesz nie otrzymać informacji dotyczących każdego pola w autoryzowanych zakresach dostępu.

Dokument opisujący

Protokół OpenID Connect wymaga użycia wielu punktów końcowych do uwierzytelniania użytkowników i żądania zasobów, w tym tokenów, informacji o użytkownikach i kluczy publicznych.

Aby uprościć implementację i zwiększyć elastyczność, OpenID Connect umożliwia użycie „dokumentu opisującego”, czyli dokumentu JSON znajdującego się w znanej lokalizacji i zawierającego pary klucz-wartość, które dostarczają szczegółowych informacji o konfiguracji dostawcy OpenID Connect, w tym identyfikatory URI punktów końcowych autoryzacji, tokena, unieważnienia, informacji o użytkowniku i kluczy publicznych. Dokument opisujący usługę OpenID Connect Google można pobrać z:

https://accounts.google.com/.well-known/openid-configuration

Aby korzystać z usług OpenID Connect od Google, musisz zakodować na stałe identyfikator URI dokumentu opisującego (https://accounts.google.com/.well-known/openid-configuration) w aplikacji. Aplikacja pobiera dokument, stosuje reguły buforowania w odpowiedzi, a następnie w razie potrzeby pobiera z niego identyfikatory URI punktów końcowych. Na przykład, aby uwierzytelnić użytkownika, kod pobierze wartość metadanych authorization_endpoint (https://accounts.google.com/o/oauth2/v2/auth w przykładzie poniżej) jako podstawowy identyfikator URI żądań uwierzytelniania wysyłanych do Google.

Oto przykład takiego dokumentu. Nazwy pól są zgodne ze specyfikacją OpenID Connect Discovery 1.0 (ich znaczenie znajdziesz w tym dokumencie). Wartości mają charakter wyłącznie ilustracyjny i mogą ulec zmianie, chociaż zostały skopiowane z najnowszej wersji rzeczywistego dokumentu opisującego Google Discovery:

{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
  "token_endpoint": "https://oauth2.googleapis.com/token",
  "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
  "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
  "response_types_supported": [
    "code",
    "token",
    "id_token",
    "code token",
    "code id_token",
    "token id_token",
    "code token id_token",
    "none"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "scopes_supported": [
    "openid",
    "email",
    "profile"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "client_secret_basic"
  ],
  "claims_supported": [
    "aud",
    "email",
    "email_verified",
    "exp",
    "family_name",
    "given_name",
    "iat",
    "iss",
    "locale",
    "name",
    "picture",
    "sub"
  ],
  "code_challenge_methods_supported": [
    "plain",
    "S256"
  ]
}

Możesz uniknąć cyklu żądanie-odpowiedź HTTP, zapisując w pamięci podręcznej wartości z dokumentu opisującego. Używane są standardowe nagłówki HTTP dotyczące przechowywania w pamięci podręcznej i należy ich przestrzegać.

Biblioteki klienta

Te biblioteki klienta ułatwiają implementację protokołu OAuth 2.0 dzięki integracji z popularnymi platformami:

• Biblioteka klienta interfejsów API Google do języka Java
• Biblioteka klienta interfejsów API Google do języka Python
• Biblioteka klienta interfejsów API Google do języka .NET
• Biblioteka klienta interfejsów API Google do języka Ruby
• Biblioteka klienta interfejsów API Google do języka PHP
• Biblioteka OAuth 2.0 dla Google Web Toolkit
• Kontrolery OAuth 2.0 w Google Toolbox for Mac

Zgodność z OpenID Connect

System uwierzytelniania OAuth 2.0 od Google obsługuje wymagane funkcje specyfikacji OpenID Connect Core. Każdy klient, który jest przeznaczony do pracy z OpenID Connect, powinien współdziałać z tą usługą (z wyjątkiem obiektu żądania OpenID).