Łączenie z kontem Google za pomocą protokołu OAuth (przepływ niejawny – zarchiwizowany)

Aby obsługiwać przepływ niejawny OAuth 2.0, usługa udostępnia punkt końcowy autoryzacji przez HTTPS. Ten punkt końcowy odpowiada za uwierzytelnianie i 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.

Gdy aplikacja Google musi wywołać jeden z autoryzowanych interfejsów API Twojej usługi, używa tego punktu końcowego, aby uzyskać od użytkowników pozwolenie na wywoływanie tych interfejsów API w ich imieniu.

Łączenie kont Google: przepływ niejawny 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 przypadku przepływu niejawnego protokołu OAuth w ramach łączenia z kontem Google (GAL). Pamiętaj, że w globalnej liście adresów Google pełni rolę klienta OAuth, a Twoja usługa – dostawcy tożsamości lub dostawcy usług.

Typowa sesja przepływu niejawnego OAuth 2.0 zainicjowana przez Google przebiega w ten sposób:

1. Google otwiera punkt końcowy autoryzacji w przeglądarce użytkownika. 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).
2. Usługa tworzy token dostępu i zwraca go do Google. Aby to zrobić, przekieruj przeglądarkę użytkownika z powrotem do Google, dołączając do żądania token dostępu.
3. Google wywołuje interfejsy API Twojej usługi i dołącza token dostępu do każdego żądania. Usługa sprawdza, czy token dostępu przyznaje Google autoryzację dostępu do interfejsu API, a następnie wykonuje wywołanie interfejsu API.

Przepis na wdrożenie

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

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

Gdy Google zainicjuje połą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 końcowy 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:none https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
   • Sprawdź, czy wartość response_type to token.

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 token dostępu:

   • Utwórz unikalny, trudny do odgadnięcia token dostępu powiązany z użytkownikiem i klientem.

4. Przekierowanie z powrotem do Google:

   • Przekieruj przeglądarkę na adres URL podany w redirect_uri.
   • Dołącz te parametry do fragmentu adresu URL (hasz):
     • access_token: wygenerowany token dostępu.
     • token_type: musi mieć wartość bearer.
     • state: niezmodyfikowana wartość stanu otrzymana od Google.

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.