Łączenie konta Google z OAuth

Konta są połączone za pomocą standardowego w branży procesu kodu autoryzacji OAuth 2.0.

OAuth 2.1 i PKCE dla agentów

W przypadku bezstanowych agentów AI i potoków multimodalnych zalecamy egzekwowanie OAuth 2.1.

  • PKCE (Proof Key for Code Exchange): musi być używany do zabezpieczenia przepływu kodu autoryzacji, aby zapobiec atakom polegającym na przechwytywaniu danych.
  • Brak przepływu niejawnego: przepływ niejawny udostępnia tokeny dostępu w adresie URL, co stanowi zagrożenie dla bezpieczeństwa środowisk agentów.

Twoja usługa musi obsługiwać punkty końcowe autoryzacji i wymiany tokenów zgodne z OAuth 2.0/2.1.

Tworzenie projektu

Aby utworzyć projekt do łączenia kont:

  1. Otwórz konsolę interfejsów API Google.
  2. Kliknij Utwórz projekt.
  3. Wpisz nazwę lub zaakceptuj wygenerowaną sugestię.
  4. Potwierdź lub edytuj pozostałe pola.
  5. Kliknij Utwórz.

Aby wyświetlić identyfikator projektu:

  1. Otwórz konsolę interfejsów API Google.
  2. Znajdź swój projekt w tabeli na stronie docelowej. Identyfikator projektu jest wyświetlany w kolumnie Identyfikator.

Proces łączenia z kontem Google obejmuje ekran zgody, na którym użytkownicy mogą zobaczyć, która aplikacja prosi o dostęp do ich danych, jakich danych żąda i jakie warunki mają zastosowanie. Zanim wygenerujesz identyfikator klienta interfejsu API Google, musisz skonfigurować ekran zgody OAuth.

  1. Otwórz stronę ekranu zgody OAuth w konsoli interfejsów API Google.
  2. Jeśli pojawi się prośba, wybierz projekt, który właśnie utworzyłeś.
  3. Na stronie „Ekran zgody OAuth” wypełnij formularz i kliknij przycisk „Zapisz”.

    Nazwa aplikacji: nazwa aplikacji, która prosi o akceptację. Nazwa powinna dokładnie odzwierciedlać Twoją aplikację i być zgodna z nazwą aplikacji, którą użytkownicy widzą w innych miejscach. Nazwa aplikacji będzie wyświetlana na ekranie zgody na łączenie kont.

    Logo aplikacji: obraz na ekranie zgody, który pomoże użytkownikom rozpoznać Twoją aplikację. Logo jest wyświetlane na ekranie zgody na łączenie kont i w ustawieniach konta.

    Adres e-mail pomocy: dla użytkowników, którzy chcą się z Tobą skontaktować w sprawie pytań o ich zgodę.

    Zakresy interfejsów API Google: zakresy umożliwiają aplikacji dostęp do prywatnych danych Google użytkownika. W przypadku łączenia z kontem Google wystarczy domyślny zakres (e-mail, profil, OpenID). Nie musisz dodawać żadnych zakresów wrażliwych. Zasadniczo najlepszym rozwiązaniem jest żądanie zakresów przyrostowo, w momencie, gdy wymagany jest dostęp, a nie z góry. Więcej informacji.

    Autoryzowane domeny: aby chronić Ciebie i Twoich użytkowników, Google pozwala na używanie autoryzowanych domen tylko aplikacjom, które uwierzytelniają się za pomocą protokołu OAuth. Linki do Twoich aplikacji muszą być hostowane w autoryzowanych domenach. Więcej informacji.

    Link do strony głównej aplikacji: strona główna Twojej aplikacji. Musi być hostowana w autoryzowanej domenie.

    Link do polityki prywatności aplikacji: Wyświetlany na ekranie zgody na łączenie kont Google. Musi być hostowana w autoryzowanej domenie.

    Link do Warunków korzystania z usługi (opcjonalnie): musi być hostowany w autoryzowanej domenie.

    Rysunek 1. Ekran zgody na łączenie z kontem Google w przypadku fikcyjnej aplikacji Tunery

  4. Sprawdź „Stan weryfikacji”. Jeśli Twoja aplikacja wymaga weryfikacji, kliknij przycisk „Prześlij do weryfikacji”, aby przesłać aplikację do weryfikacji. Szczegółowe informacje znajdziesz w wymaganiach dotyczących weryfikacji OAuth.

Implementowanie serwera OAuth

Implementacja serwera OAuth 2.0 przepływu kodu autoryzacji składa się z 2 punktów końcowych, które usługa udostępnia przez HTTPS. Pierwszy punkt końcowy to punkt końcowy autoryzacji, który odpowiada za znajdowanie lub uzyskiwanie zgody użytkowników na dostęp do danych. Punkt końcowy autoryzacji wyświetla interfejs logowania użytkownikom, którzy nie są jeszcze zalogowani, i rejestruje zgodę na żądany dostęp. Drugi punkt końcowy to punkt końcowy wymiany tokenów, który służy do uzyskiwania zaszyfrowanych ciągów znaków, zwanych tokenami, które autoryzują użytkownika do uzyskiwania dostępu do Twojej usługi.

Gdy aplikacja Google musi wywołać jeden z interfejsów API Twojej usługi, używa tych punktów końcowych, aby uzyskać od użytkowników uprawnienia do wywoływania tych interfejsów API w ich imieniu.

Łączenie z kontem Google: przepływ kodu autoryzacji OAuth

Poniższy diagram sekwencji przedstawia interakcje między użytkownikiem, Google a punktami końcowymi Twojej usługi.

Użytkownik Aplikacja Google / Przeglądarka Serwer Google Punkt końcowy autoryzacji Punkt końcowy tokena 1. Użytkownik inicjuje połączenie 2. Przekierowanie do punktu końcowego autoryzacji (GET) client_id, redirect_uri, state, scope 3. Wyświetl ekran logowania i zgody 4. Użytkownik uwierzytelnia się i wyraża zgodę 5. Przekierowanie z powrotem do Google (GET) code, state 6. Obsługa przekierowania i przekazywanie kodu lub stanu 7. Wymiana tokena (POST) grant_type=authorization_code, code 8. Zwróć tokeny (200 OK) access_token, refresh_token 9. Przechowywanie tokenów użytkownika 10. Dostęp do zasobów użytkownika
Rysunek 1. Sekwencja zdarzeń w przepływie kodu autoryzacji OAuth 2.0 na potrzeby łączenia z kontem Google.

Role i obowiązki

W tabeli poniżej znajdziesz definicje ról i obowiązków podmiotów uczestniczących w procesie OAuth łączenia z kontem Google (GAL). Pamiętaj, że w GAL Google pełni rolę klienta OAuth, a Twoja usługa – dostawcy tożsamości lub usługi.

Użytkownik, który wykonał czynność / komponent Rola GAL Podmiot odpowiedzialny
Aplikacja / serwer Google Klient OAuth Inicjuje proces, odbiera kod autoryzacji, wymienia go na tokeny i bezpiecznie je przechowuje, aby uzyskać dostęp do interfejsów API usługi.
Punkt końcowy autoryzacji Serwer autoryzacji Uwierzytelnia użytkowników i uzyskuje ich zgodę na udostępnianie Google dostępu do ich danych.
Punkt końcowy wymiany tokenów Serwer autoryzacji Weryfikuje kody autoryzacji i tokeny odświeżania oraz wydaje tokeny dostępu na serwer Google.
Identyfikator URI przekierowania Google Punkt końcowy wywołania zwrotnego Otrzymuje przekierowanie użytkownika z usługi autoryzacji z wartościami codestate.

Sesja przepływu kodu autoryzacji OAuth 2.0 zainicjowana przez Google przebiega w ten sposób:

  1. Google otwiera punkt końcowy autoryzacji w przeglądarce użytkownika. Jeśli przepływ został rozpoczęty na urządzeniu obsługującym tylko głos w przypadku działania, Google przenosi wykonanie na telefon.
  2. Użytkownik loguje się (jeśli nie jest jeszcze zalogowany) i przyznaje Google uprawnienia dostępu do swoich danych za pomocą Twojego interfejsu API (jeśli nie zrobił tego wcześniej).
  3. Usługa tworzy kod autoryzacji i zwraca go do Google. Aby to zrobić, przekieruj przeglądarkę użytkownika z powrotem do Google z kodem autoryzacji dołączonym do żądania.
  4. Google wysyła kod autoryzacji do punktu końcowego wymiany tokenów, który weryfikuje autentyczność kodu i zwraca token dostępu oraz token odświeżania. Token dostępu to krótkoterminowy token, który Twoja usługa akceptuje jako dane logowania umożliwiające dostęp do interfejsów API. Token odświeżania to token o długim okresie ważności, który Google może przechowywać i używać do uzyskiwania nowych tokenów dostępu po wygaśnięciu poprzednich.
  5. Po zakończeniu przez użytkownika procesu łączenia konta każde kolejne żądanie wysyłane z Google zawiera token dostępu.

Przepis na wdrożenie

Aby wdrożyć przepływ kodu autoryzacji, wykonaj te czynności.

Krok 1. Obsługa próśb o autoryzację

Gdy Google rozpocznie łączenie kont, przekieruje użytkownika do Twojego punktu końcowego autoryzacji. Szczegółowe informacje o umowach protokołu i wymaganiach dotyczących parametrów znajdziesz w sekcji Punkt autoryzacji.

Aby obsłużyć prośbę, wykonaj te czynności:

  1. Sprawdź prośbę:

    • Sprawdź, czy client_id odpowiada identyfikatorowi klienta przypisanemu do Google.
    • Sprawdź, czy redirect_uri jest zgodny z oczekiwanym adresem URL przekierowania Google:
      • Prod: https://oauth-redirect.googleusercontent.com/r/YOUR_PARTNER_ID
      • Piaskownica: https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PARTNER_ID
    • Sprawdź, czy response_type to code.
  2. Uwierzytelnij użytkownika:

    • Sprawdź, czy użytkownik jest zalogowany w Twojej usłudze.
    • Jeśli użytkownik nie jest zalogowany, poproś go o wykonanie czynności wymaganych do zalogowania się lub zarejestrowania.
  3. Wygeneruj kod autoryzacji:

    • Utwórz unikalny, trudny do odgadnięcia kod autoryzacji powiązany z użytkownikiem i klientem.
    • Ustaw wygaśnięcie kodu za około 10 minut.
  4. Przekierowanie z powrotem do Google:

    • Przekieruj przeglądarkę na adres URL podany w redirect_uri.
    • Dołącz te parametry zapytania:
      • code: wygenerowany kod autoryzacji.
      • state: niezmodyfikowana wartość stanu otrzymana od Google.

Krok 2. Obsługa próśb o wymianę tokena

Punkt końcowy wymiany tokenów przetwarza 2 rodzaje żądań: wymianę kodów na tokeny i odświeżanie wygasłych tokenów dostępu. Szczegółowe informacje o kontraktach protokołu i wymaganiach dotyczących parametrów znajdziesz w artykule Punkt końcowy wymiany tokenów.

A. Wymiana kodów autoryzacji na tokeny

Gdy Google otrzyma kod autoryzacji, wywoła punkt końcowy wymiany tokenów (POST), aby pobrać tokeny.

  1. Sprawdź prośbę:

    • Sprawdź client_idclient_secret.
    • Sprawdź, czy kod autoryzacji jest prawidłowy i nie stracił ważności.
    • Sprawdź, czy wartość redirect_uri jest zgodna z wartością używaną w kroku 1.
    • Jeśli weryfikacja się nie powiedzie, zwróć błąd HTTP 400 Bad Request z kodem {"error": "invalid_grant"}.
  2. Wydawanie tokenów:

    • Wygeneruj token o długim refresh_token i krótkim access_token okresie ważności (zwykle 1 godzina).
    • Zwróć kod HTTP 200 OK ze standardową odpowiedzią tokena w formacie JSON.

B. Odświeżanie tokenów dostępu

Gdy token dostępu wygaśnie, Google poprosi o nowy token za pomocą tokena odświeżania.

  1. Sprawdź prośbę:

    • Sprawdź client_id, client_secretrefresh_token.
    • Jeśli weryfikacja się nie powiedzie, zwróć błąd HTTP 400 Bad Request z kodem {"error": "invalid_grant"}.
  2. Wydaj nowy token dostępu:

    • Wygeneruj nowy krótkotrwały access_token.
    • Zwróć kod HTTP 200 OK z odpowiedzią tokena JSON (opcjonalnie z nowym tokenem odświeżania).
Obsługa żądań informacji o użytkowniku

Punkt końcowy informacji o użytkowniku jest chronionym przez OAuth 2.0 zasobem, który zwraca deklaracje dotyczące połączonego użytkownika. Wdrożenie i hosting punktu końcowego informacji o użytkowniku jest opcjonalne. Wyjątkiem są te przypadki użycia:

Po pobraniu tokena dostępu z punktu końcowego tokena Google wysyła żądanie do punktu końcowego informacji o użytkowniku, aby pobrać podstawowe informacje profilowe połączonego użytkownika.

nagłówki żądań punktu końcowego informacji o użytkowniku
Authorization header Token dostępu typu okaziciela.

Jeśli na przykład punkt końcowy informacji o użytkowniku jest dostępny pod adresem https://myservice.example.com/userinfo, żądanie może wyglądać tak:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

Aby punkt końcowy informacji o użytkowniku mógł obsługiwać żądania, wykonaj te czynności:

  1. Wyodrębnij token dostępu z nagłówka autoryzacji i zwróć informacje o użytkowniku powiązanym z tym tokenem.
  2. Jeśli token dostępu jest nieprawidłowy, zwróć błąd HTTP 401 (Brak autoryzacji) i użyj nagłówka odpowiedzi WWW-Authenticate. Poniżej znajduje się przykładowa odpowiedź na pytanie o błąd w informacjach o użytkowniku:
    HTTP/1.1 401 Unauthorized
    WWW-Authenticate: error="invalid_token",
    error_description="The Access Token expired"
    
    Jeśli podczas procesu łączenia pojawi się błąd 401 (Brak autoryzacji) lub inna nieudana próba połączenia, błędu nie będzie można odzyskać, pobrany token zostanie odrzucony, a użytkownik będzie musiał ponownie zainicjować proces łączenia.
  3. Jeśli token dostępu jest prawidłowy, zwróć odpowiedź HTTP 200 z podanym niżej obiektem JSON w treści HTTPS odpowiedź:

    {
    "sub": "USER_UUID",
    "email": "EMAIL_ADDRESS",
    "given_name": "FIRST_NAME",
    "family_name": "LAST_NAME",
    "name": "FULL_NAME",
    "picture": "PROFILE_PICTURE",
    }
    Jeśli punkt końcowy informacji o użytkowniku zwraca odpowiedź HTTP 200, pobrany token i żądania są rejestrowane dla konta Google użytkownika.

    odpowiedź dotycząca punktu końcowego informacji o użytkowniku
    sub Unikalny identyfikator, który identyfikuje użytkownika w Twoim systemie.
    email Adres e-mail użytkownika.
    given_name Opcjonalnie: imię użytkownika.
    family_name Opcjonalnie: nazwisko użytkownika.
    name Opcjonalnie: pełna nazwa użytkownika.
    picture Opcjonalnie: zdjęcie profilowe użytkownika.

Sprawdzanie poprawności implementacji

Implementację możesz zweryfikować za pomocą narzędzia OAuth 2.0 Playground.

W narzędziu wykonaj te czynności:

  1. Kliknij Konfiguracja , aby otworzyć okno Konfiguracja OAuth 2.0.
  2. W polu OAuth flow (Proces OAuth) wybierz Client-side (Po stronie klienta).
  3. W polu Punkty końcowe OAuth wybierz Niestandardowe.
  4. W odpowiednich polach podaj punkt końcowy OAuth 2.0 i identyfikator klienta przypisany do Google.
  5. W sekcji Krok 1 nie wybieraj żadnych zakresów Google. Zamiast tego pozostaw to pole puste lub wpisz zakres ważny dla Twojego serwera (albo dowolny ciąg znaków, jeśli nie używasz zakresów OAuth). Gdy skończysz, kliknij Autoryzuj interfejsy API.
  6. W sekcjach Krok 2Krok 3 przejdź przez przepływ OAuth 2.0 i sprawdź, czy każdy krok działa zgodnie z oczekiwaniami.

Możesz sprawdzić, czy implementacja jest prawidłowa, korzystając z narzędzia Google Account Linking Demo.

W narzędziu wykonaj te czynności:

  1. Kliknij przycisk Zaloguj się przez Google.
  2. Wybierz konto, które chcesz połączyć.
  3. Wpisz identyfikator usługi.
  4. Opcjonalnie wpisz co najmniej jeden zakres, do którego chcesz uzyskać dostęp.
  5. Kliknij Uruchom wersję pokazową.
  6. Gdy pojawi się komunikat, potwierdź, że możesz wyrazić zgodę na prośbę o połączenie lub ją odrzucić.
  7. Sprawdź, czy nastąpiło przekierowanie na Twoją platformę.