Łączenie konta Google z OAuth

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

OAuth 2.1 i PKCE w przypadku agentów

W przypadku bezstanowych agentów AI i wielomodowych potoków zalecane jest egzekwowanie OAuth 2.1.

• PKCE (Proof Key for Code Exchange): musi być używany do zabezpieczania przepływu kodu autoryzacji, co zapobiega atakom polegającym na przechwytywaniu.
• 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.

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

Create the project

To create your project to use account linking:

1. Go to the Google API Console.
2. Click Create project.
3. Enter a name or accept the generated suggestion.
4. Confirm or edit any remaining fields.
5. Click Create.

To view your project ID:

1. Go to the Google API Console.
2. Find your project in the table on the landing page. The project ID appears in the ID column.

Configure your OAuth Consent Screen

The Google Account Linking process includes a consent screen which tells users the application requesting access to their data, what kind of data they are asking for and the terms that apply. You will need to configure your OAuth consent screen before generating a Google API client ID.

1. Open the OAuth consent screen page of the Google APIs console.
2. If prompted, select the project you just created.

3. On the "OAuth consent screen" page, fill out the form and click the “Save” button.

   Application name: The name of the application asking for consent. The name should accurately reflect your application and be consistent with the application name users see elsewhere. The application name will be shown on the Account Linking consent screen.

   Application logo: An image on the consent screen that will help users recognize your app. The logo is shown on Account linking consent screen and on account settings

   Support email: For users to contact you with questions about their consent.

   Scopes for Google APIs: Scopes allow your application to access your user's private Google data. For the Google Account Linking use case, default scope (email, profile, openid) is sufficient, you don’t need to add any sensitive scopes. It is generally a best practice to request scopes incrementally, at the time access is required, rather than up front. Learn more.

   Authorized domains: To protect you and your users, Google only allows applications that authenticate using OAuth to use Authorized Domains. Your applications' links must be hosted on Authorized Domains. Learn more.

   Application Homepage link: Home page for your application. Must be hosted on an Authorized Domain.

   Application Privacy Policy link: Shown on Google Account Linking consent screen. Must be hosted on an Authorized Domain.

   Application Terms of Service link (Optional): Must be hosted on an Authorized Domain.

   

   Figure 1. Google Account Linking Consent Screen for a fictitious Application, Tunery

4. Check "Verification Status", if your application needs verification then click the "Submit For Verification" button to submit your application for verification. Refer to OAuth verification requirements for details.

Wdrażanie serwera OAuth

Implementacja serwera OAuth 2.0 w ramach przepływu kodu autoryzacji obejmuje 2 punkty końcowe, które Twoja 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 użytkownikom, którzy nie są jeszcze zalogowani, interfejs logowania 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 korzystania z Twojej usługi.

Gdy aplikacja Google musi wywołać jeden z interfejsów API Twojej usługi, Google używa tych punktów końcowych razem, aby uzyskać od użytkowników zgodę na wywoływanie 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 i punktami końcowymi Twojej usługi.

Role i obowiązki

W tabeli poniżej zdefiniowano role i obowiązki podmiotów w przepływie protokołu OAuth łączenia z kontem Google (GAL). Pamiętaj, że w przypadku łączenia kont Google pełni rolę OAuth klienta, a Twoja usługa – rolę dostawcy tożsamości/usługi.

Sesja przepływu kodu autoryzacji OAuth 2.0 zainicjowana przez Google ma następujący przebieg:

1. Google otwiera Twój punkt końcowy autoryzacji w przeglądarce użytkownika. Jeśli przepływ został uruchomiony 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 przyznał jeszcze uprawnień).
3. Twoja 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 Twojego punktu końcowego wymiany tokenów, który sprawdza autentyczność kodu i zwraca token dostępu oraz token odświeżania. Token dostępu to token o krótkim okresie ważności, który Twoja usługa akceptuje jako dane logowania 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 ich wygaśnięciu.
5. Gdy użytkownik zakończy proces łączenia kont, każde kolejne żądanie wysyłane z Google będzie zawierać token dostępu.

Przepis na implementację

Aby zaimplementować przepływ kodu autoryzacji, wykonaj te czynności.

Krok 1. Obsługa żądań autoryzacji

Gdy Google inicjuje łączenie kont, przekierowuje 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 końcowy autoryzacji.

Aby obsłużyć żądanie, wykonaj te czynności:

1. Sprawdź żądanie:

   • Potwierdź, że client_id odpowiada identyfikatorowi klienta przypisanemu do Google.
   • Potwierdź, że redirect_uri odpowiada oczekiwanemu adresowi URL przekierowania Google: none https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
   • Sprawdź, czy response_type ma wartość 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 koniecznych do zalogowania się lub zarejestrowania.

3. Wygeneruj kod autoryzacji:

   • Utwórz unikalny kod autoryzacji, którego nie można odgadnąć, powiązany z użytkownikiem i klientem.
   • Ustaw ważność kodu na około 10 minut.

4. Przekieruj z powrotem do Google:

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

Krok 2. Obsługa żądań wymiany tokenów

Twój 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 umowach protokołu i wymaganiach dotyczących parametrów znajdziesz w sekcji Punkt końcowy wymiany tokenów.

A. Wymiana kodów autoryzacji na tokeny

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

1. Sprawdź żądanie:

   • Sprawdź client_id i client_secret.
   • Sprawdź, czy kod autoryzacji jest prawidłowy i nie wygasł.
   • Potwierdź, że redirect_uri odpowiada wartości użytej w kroku 1.
   • Jeśli weryfikacja się nie powiedzie, zwróć kod HTTP 400 Bad Request z wartością {"error": "invalid_grant"}.

2. Wydaj tokeny:

   • Wygeneruj token refresh_token o długim okresie ważności i token access_token o krótkim 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ź żądanie:

   • Sprawdź client_id, client_secret i refresh_token.
   • Jeśli weryfikacja się nie powiedzie, zwróć kod HTTP 400 Bad Request z wartością {"error": "invalid_grant"}.

2. Wydaj nowy token dostępu:

   • Wygeneruj nowy token access_token o krótkim okresie ważności.
   • Zwróć kod HTTP 200 OK z odpowiedzią tokena w formacie JSON (opcjonalnie z nowym tokenem odświeżania).

Handle userinfo requests

The userinfo endpoint is an OAuth 2.0 protected resource that return claims about the linked user. Implementing and hosting the userinfo endpoint is optional, except for the following use cases:

• Linked Account Sign-In with Google One Tap.
• Frictionless subscription on AndroidTV.

After the access token has been successfully retrieved from your token endpoint, Google sends a request to your userinfo endpoint to retrieve basic profile information about the linked user.

For example, if your userinfo endpoint is available at https://myservice.example.com/userinfo, a request might look like the following:

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

For your userinfo endpoint to handle requests, do the following steps:

1. Extract access token from the Authorization header and return information for the user associated with the access token.
2. If the access token is invalid, return an HTTP 401 Unauthorized error with using the WWW-Authenticate Response Header. Below is an example of a userinfo error response:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

   If a 401 Unauthorized, or any other unsuccessful error response is returned during the linking process, the error will be non-recoverable, the retrieved token will be discarded and the user will have to initiate the linking process again.

3. If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response:

   {
   "sub": "USER_UUID",
   "email": "EMAIL_ADDRESS",
   "given_name": "FIRST_NAME",
   "family_name": "LAST_NAME",
   "name": "FULL_NAME",
   "picture": "PROFILE_PICTURE",
   }

   If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.

   userinfo endpoint response
   sub	A unique ID that identifies the user in your system.
   email	Email address of the user.
   given_name	Optional: First name of the user.
   family_name	Optional: Last name of the user.
   name	Optional: Full name of the user.
   picture	Optional: Profile picture of the user.

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 settings, 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 2 i Krok 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ę.