AuthSub w bibliotekach klienta protokołu danych Google

Ostrzeżenie: ta strona dotyczy starszych interfejsów API Google, czyli interfejsów Google Data API. Jest ona istotna tylko w przypadku interfejsów API wymienionych w katalogu interfejsów Google Data API, z których wiele zostało zastąpionych nowszymi interfejsami API. Informacje o konkretnym nowym interfejsie API znajdziesz w jego dokumentacji. Informacje o autoryzowaniu żądań za pomocą nowszego interfejsu API znajdziesz w artykule Uwierzytelnianie i autoryzacja kont Google.

W tym dokumencie opisujemy, jak za pomocą bibliotek klienta Google Data API łączyć się z uwierzytelnianiem AuthSub w aplikacjach internetowych.

Interfejs AuthSub umożliwia aplikacji internetowej dostęp do usługi Google w imieniu użytkownika. Aby zachować wysoki poziom bezpieczeństwa, interfejs AuthSub umożliwia aplikacji uzyskanie tokena uwierzytelniania bez konieczności obsługi danych logowania użytkownika.

Biblioteki klienta Google Data API udostępniają metody, które pomagają korzystać z AuthSub w aplikacji internetowej. Istnieją w nim metody tworzenia adresu URL żądania, uzyskiwania jednorazowego tokena uwierzytelniania, wymiany jednorazowego tokena na token sesji i podpisywania żądania.

Uwaga: biblioteka klienta JavaScript ma własną wersję AuthSub o nazwie AuthSubJS. Informacje o tym, jak używać AuthSubJS w aplikacjach JavaScript, znajdziesz w artykule Używanie uwierzytelniania „AuthSub” z biblioteką klienta JavaScript.

Odbiorcy

Ten dokument jest przeznaczony dla programistów, którzy chcą, aby ich aplikacje internetowe uzyskiwały dostęp do usług Google w imieniu użytkowników za pomocą bibliotek klienta interfejsów API danych Google.

W tym dokumencie zakładamy, że znasz interfejs AuthSub i ogólny proces wdrażania AuthSub w aplikacji internetowej. Pełny opis protokołu AuthSub znajdziesz w artykule Uwierzytelnianie AuthSub w aplikacjach internetowych.

Korzystanie z AuthSub i interfejsów Google Data API bez bibliotek klienta

Jeśli chcesz, aby klient aplikacji internetowej wchodził w interakcje z usługą danych Google przy użyciu AuthSub jako systemu uwierzytelniania, wszystkie potrzebne informacje znajdziesz w artykule Uwierzytelnianie AuthSub w aplikacjach internetowych. Jeśli nie chcesz, nie musisz używać bibliotek klienta interfejsów Google Data API.

Oto schemat uwierzytelniania użytkownika w aplikacji za pomocą AuthSub:

Aplikacja tworzy odpowiedni adres URL AuthSub, a następnie przekierowuje użytkownika na ten adres, aby mógł się zalogować. System AuthSub przekierowuje użytkownika z powrotem na określony przez Ciebie adres URL w Twojej witrynie i zwraca token jednorazowy. Aplikacja może opcjonalnie wymienić ten token na token sesji. Następnie aplikacja wysyła token w nagłówku autoryzacji z każdym żądaniem wysyłanym do usługi.

Biblioteki klienta interfejsów API danych Google upraszczają ten proces autoryzacji, ponieważ obsługują różne szczegóły. Z tego dokumentu dowiesz się, jak to zrobić.

Praca z AuthSub i interfejsami Google Data API: przykłady bibliotek klienta

W tej sekcji znajdziesz przykład użycia metod biblioteki klienta interfejsów Google Data API do wykonania czynności opisanych w sekcji „Korzystanie z AuthSub” w dokumentacji AuthSub.

W tym przykładzie integrujemy interfejs AuthSub z aplikacją internetową, która wchodzi w interakcję z Kalendarzem Google (chociaż nie musisz nic wiedzieć o Kalendarzu Google, aby zrozumieć ten przykład). W tym przykładzie zakłada się, że aplikacja internetowa jest hostowana pod adresem example.com.

Zdecyduj, jakiego rodzaju tokena chcesz użyć (session=0 lub session=1).

Możesz używać tokenów jednorazowych (session=0) lub tokenów sesji (session=1). W tym dokumencie będziemy używać tokenów sesji, ponieważ są one bardziej przydatne w aplikacjach, które wysyłają wiele żądań do interfejsu API. Zgodnie z dokumentacją AuthSub, jeśli zdecydujesz się używać w aplikacji internetowej tokenów sesji, musisz samodzielnie zarządzać przechowywaniem tokenów. Ten dokument nie obejmuje zarządzania tokenami. Pamiętaj też, że tokenów żądanych za pomocą parametru session=0 nie można później wymienić (zaktualizować) na token sesji o długim okresie ważności.

Zdecyduj, czy chcesz zarejestrować aplikację internetową (secure=0 lub secure=1).

AuthSub może być używany w 3 trybach: niezarejestrowanym, zarejestrowanym i zarejestrowanym z zwiększonym poziomem bezpieczeństwa. W dalszej części tego dokumentu będziemy odnosić się do ostatniej opcji jako bezpiecznego AuthSub. Chociaż tryb niezarejestrowany/zarejestrowany jest prostszy w konfiguracji niż bezpieczny AuthSub, Google zachęca do używania bezpiecznych tokenów ze względu na ich większe bezpieczeństwo.

Jak się zarejestrować

Wybór opcji Rejestracja aplikacji internetowych daje aplikacji te korzyści:

1. wyższy poziom bezpieczeństwa;
2. Google ufa aplikacji (na stronie autoryzacji Google nie wyświetla się ostrzeżenie dla użytkownika).

Zarejestrowane + bezpieczne AuthSub

Jeśli zdecydujesz się na bezpieczną autoryzację AuthSub, oprócz zarejestrowania aplikacji internetowej musisz utworzyć parę klucza prywatnego RSA i certyfikatu publicznego z podpisem własnym. Przykłady tworzenia certyfikatów X.509 znajdziesz w sekcji Generowanie kluczy i certyfikatów do użycia w trybie zarejestrowanym (poniżej).

Określanie zakresu dostępu do danych

Każda usługa Google definiuje wartość scope, która określa (i ewentualnie ogranicza) dostęp tokena do danych użytkownika. Listę dostępnych wartości scope znajdziesz w najczęstszych pytaniach.

Ponieważ zdecydowaliśmy się na korzystanie z interfejsu Google Calendar API, scope powinno być http://www.google.com/calendar/feeds/.

Uwaga: zawsze ustawiaj wartość zakresu na najszerszy możliwy adres URL, chyba że potrzebujesz bardziej precyzyjnego ograniczenia. Na przykład węższy zakres, taki jak scope=http://www.google.com/calendar/feeds/default/allcalendars/full, ograniczy dostęp tokena tylko do wszystkich kalendarzy lub pełnego pliku danych. Użycie scope=http://www.google.com/calendar/feeds/ umożliwi dostęp do wszystkich kanałów Kalendarza: http://www.google.com/calendar/feeds/*.

Tokeny o wielu zakresach

Aby utworzyć tokeny, które uzyskują dostęp do wielu interfejsów Google Data API, oddziel każdy zakres zakodowaną w URL spacją. Poniższy przykład tworzy token, który będzie mieć dostęp do danych użytkownika w Kontaktach Google i Kalendarzu Google.

scope=http://www.google.com/calendar/feeds/%20http://www.google.com/m8/feeds/

Wysyłanie prośby o token uwierzytelniania jednorazowego użytku

Aby uzyskać token AuthSub dla danego użytkownika i danej usługi, aplikacja musi przekierować użytkownika na adres URL AuthSubRequest, który wyświetli prośbę o zalogowanie się na konto Google. (Więcej informacji o adresie URL AuthSubRequest znajdziesz w pełnej wersji artykułu Uwierzytelnianie AuthSub w aplikacjach internetowych).

Aby utworzyć adres URL AuthSubRequest w aplikacji, użyj w przypadku każdej biblioteki klienta tych informacji:

Java

import com.google.gdata.client.*;

String nextUrl = "http://www.example.com/RetrieveToken.jsp";
String scope = "http://www.google.com/calendar/feeds/";
boolean secure = false;  // set secure=true to request secure AuthSub tokens
boolean session = true;
String authSubUrl = AuthSubUtil.getRequestUrl(nextUrl, scope, secure, session);

Jeśli chcesz uwierzytelniać użytkowników w domenie G Suite:

import com.google.gdata.client.*;

String hostedDomain = "example.com";
String nextUrl = "http://www.example.com/RetrieveToken.jsp";
String scope = "http://www.google.com/calendar/feeds/";
boolean secure = false;  // set secure=true to request AuthSub tokens
boolean session = true;
String authSubUrl = AuthSubUtil.getRequestUrl(hostedDomain, nextUrl, scope, secure, session);

.NET

using Google.GData.Client;

String nextUrl = "http://www.example.com/RetrieveToken.aspx";
String scope = "http://www.google.com/calendar/feeds/";
bool secure = false; // set secure=true to request secure AuthSub tokens
bool session = true;
String authSubUrl = AuthSubUtil.getRequestUrl(nextUrl, scope, secure, session);

Jeśli chcesz uwierzytelniać użytkowników w domenie G Suite:

using Google.GData.Client;

String hostedDomain = "example.com";
String nextUrl = "http://www.example.com/RetrieveToken.aspx";
String scope = "http://www.google.com/calendar/feeds/";
bool secure = false; // set secure=true to request secure AuthSub tokens
bool session = true;
String authSubUrl = AuthSubUtil.getRequestUrl(hostedDomain, nextUrl, scope, secure, session);

PHP

require_once 'Zend/Loader.php';
Zend_Loader::loadClass('Zend_Gdata_AuthSub');

$nextUrl = 'http://www.example.com/RetrieveToken.php';
$scope = 'http://www.google.com/calendar/feeds/';
$secure = 0;  // set $secure=1 to request secure AuthSub tokens
$session = 1;
$authSubUrl = Zend_Gdata_AuthSub::getAuthSubTokenUri($nextUrl, $scope, $secure, $session);

Jeśli chcesz uwierzytelniać użytkowników w domenie G Suite:

require_once 'Zend/Loader.php';
Zend_Loader::loadClass('Zend_Gdata_AuthSub');

$hostedDomain = 'example.com';
$nextUrl = 'http://www.example.com/RetrieveToken.php';
$scope = 'http://www.google.com/calendar/feeds/';
$secure = 0;  // set $secure=1 to request secure AuthSub tokens
$session = 1;
$authSubUrl = Zend_Gdata_AuthSub::getAuthSubTokenUri($nextUrl, $scope, $secure, $session) . '&hd=' . $hostedDomain;

Python

import gdata.auth

next = 'http://www.example.com/RetrieveToken.pyc'
scope = 'http://www.google.com/calendar/feeds/'
secure = False  # set secure=True to request secure AuthSub tokens
session = True
auth_sub_url = gdata.auth.GenerateAuthSubRequestUrl(next, scope, secure=secure, session=session)

Jeśli chcesz uwierzytelniać użytkowników w domenie G Suite:

import gdata.auth

hosted_domain = 'example.com'
next = 'http://www.example.com/RetrieveToken.pyc'
scope = 'http://www.google.com/calendar/feeds/'
secure = False  # set secure=True to request secure AuthSub tokens
session = True
auth_sub_url = gdata.auth.GenerateAuthSubRequestUrl(next, scope, secure=secure, session=session, domain=hosted_domain)

Po utworzeniu adresu URL „next” aplikacja może go używać na różne sposoby, aby przekierować użytkownika do AuthSubRequest obsługi. Najczęstszym podejściem jest wyświetlenie strony, która informuje użytkownika, że musi kliknąć link, aby autoryzować aplikację do uzyskiwania dostępu do jego konta Google. Następnie dołącz do linku adres URL żądania. Możesz na przykład wyświetlić w aplikacji internetowej ten ciąg znaków:

String authorizationUrl =
        "<p>MyApp needs access to your Google Calendar account to read your Calendar feed. " +
        "To authorize MyApp to access your account, <a href=\"" + authSubUrl + "\">log in to your account</a>.</p>";

Użytkownik klika link do strony AuthSub w Google i się loguje. System AuthSub przekierowuje użytkownika z powrotem do aplikacji, używając podanego przez Ciebie adresu URL „next”.

Wyodrębnianie tokena jednorazowego użytku

Gdy Google przekieruje użytkownika z powrotem do Twojej aplikacji, token zostanie dołączony do adresu URL „next” jako parametr zapytania. W przypadku powyższych przykładów po zalogowaniu się użytkownika Google przekierowuje go na adres URL podobny do http://www.example.com/RetrieveToken?token=DQAADKEDE. Aplikacja powinna wyodrębnić wartość tokena z parametru zapytania w adresie URL.

Jeśli aplikacja ustawiła w przeglądarce użytkownika plik cookie uwierzytelniania przed przekierowaniem go do systemu AuthSub, to gdy Google przekieruje użytkownika z powrotem do adresu URL „next”, aplikacja będzie mogła odczytać plik cookie uwierzytelniania, aby rozpoznać, który użytkownik dotarł do tego adresu URL. Możesz użyć takiego pliku cookie, aby powiązać identyfikator użytkownika w aplikacji z tokenem AuthSub pobranym z Google.

Biblioteki klienta udostępniają wygodne metody wyodrębniania tokena jednorazowego użytku:

Java

String singleUseToken = AuthSubUtil.getTokenFromReply(httpServletRequest.getQueryString());

.NET

String singleUseToken = Request.QueryString["token"];
// or
String singleUseToken = AuthSubUtil.getTokenFromReply(new Uri(Request.QueryString));

PHP

$singleUseToken = $_GET['token'];

Python

current_url = 'http://' + req.hostname + req.unparsed_uri
# Unlike the other calls, extract_auth_sub_token_from_url() will create an AuthSubToken or SecureAuthSubToken object.
# Use str(single_use_token) to return the token's string value.
single_use_token = gdata.auth.extract_auth_sub_token_from_url(current_url)

Jeśli używasz bezpiecznego AuthSub, ustaw klucz prywatny RSA, aby utworzyć SecureAuthSubToken:

f = open('/path/to/yourRSAPrivateKey.pem')
rsa_key = f.read()
f.close()
current_url = 'http://' + req.hostname + req.unparsed_uri
# Unlike the other calls, extract_auth_sub_token_from_url() will create an AuthSubToken or SecureAuthSubToken object.
# Use str(single_use_token) to return the token's string value.
single_use_token = gdata.auth.extract_auth_sub_token_from_url(current_url, rsa_key=rsa_key)

Prośba o token sesji

Token uzyskany z adresu URL jest zawsze tokenem jednorazowym. Następnym krokiem jest uaktualnienie tego tokena do tokena sesji o długim okresie ważności za pomocą adresu URL AuthSubSessionToken, zgodnie z opisem w pełnej dokumentacji Uwierzytelnianie AuthSub w aplikacjach internetowych. Jeśli używasz bezpiecznego AuthSub, przed wymianą musisz ustawić klucz prywatny RSA. Oto kilka przykładów użycia poszczególnych bibliotek klienta:

Java

import com.google.gdata.client.*;
import com.google.gdata.client.calendar.*;

String sessionToken = AuthSubUtil.exchangeForSessionToken(singleUseToken, null);

CalendarService calendarService = new CalendarService("google-ExampleApp-v1.0");
calendarService.setAuthSubToken(sessionToken, null);

// ready to interact with Calendar feeds

W przypadku bezpiecznego uwierzytelniania AuthSub przekaż klucz prywatny RSA do exchangeForSessionToken zamiast do null:

import com.google.gdata.client.*;
import com.google.gdata.client.calendar.*;

java.security.PrivateKey privateKey =
    AuthSubUtil.getPrivateKeyFromKeystore("AuthSubExample.jks", "privKeyPa$$word", "AuthSubExample", "privKeyPa$$word");
String sessionToken = AuthSubUtil.exchangeForSessionToken(singleUseToken, privateKey);

CalendarService calendarService = new CalendarService("google-ExampleApp-v1.0");
calendarService.setAuthSubToken(sessionToken, privateKey);

// ready to interact with Calendar feeds

.NET

using Google.GData.Client;
using Google.GData.Calendar;

String sessionToken = AuthSubUtil.exchangeForSessionToken(singleUseToken, null).ToString();

GAuthSubRequestFactory authFactory = new GAuthSubRequestFactory("cl", "google-ExampleApp-v1.0");
authFactory.Token = (String) sessionToken;

CalendarService calendarService = new CalendarService(authFactory.ApplicationName);
calendarService.RequestFactory = authFactory;

// ready to interact with Calendar feeds

W przypadku bezpiecznego uwierzytelniania AuthSub przekaż klucz prywatny RSA do exchangeForSessionToken zamiast do null:

using Google.GData.Client;
using Google.GData.Calendar;

protected AsymmetricAlgorithm getRsaKey()
{
  X509Certificate2 cert = new X509Certificate2("C:/MyAspSite/test_cert.pfx", "privKeyPa$$word");
  RSACryptoServiceProvider privateKey = cert.PrivateKey as RSACryptoServiceProvider;
  return privateKey;
}

AsymmetricAlgorithm rsaKey = getRsaKey();
String sessionToken = AuthSubUtil.exchangeForSessionToken(singleUseToken, rsaKey).ToString();

GAuthSubRequestFactory authFactory = new GAuthSubRequestFactory("cl", "google-ExampleApp-v1.0");
authFactory.Token = (String) sessionToken;
authFactory.PrivateKey = rsaKey;

CalendarService calendarService = new CalendarService(authFactory.ApplicationName);
calendarService.RequestFactory = authFactory;

// ready to interact with Calendar feeds

PHP

require_once 'Zend/Loader.php';
Zend_Loader::loadClass('Zend_Gdata_AuthSub');
Zend_Loader::loadClass('Zend_Gdata_Calendar');

$sessionToken = Zend_Gdata_AuthSub::getAuthSubSessionToken($singleUseToken);

// Create a Calendar service object and set the session token for subsequent requests
$calendarService = new Zend_Gdata_Calendar(null, 'google-ExampleApp-v1.0');
$calendarService->setAuthSubToken($sessionToken);

// ready to interact with Calendar feeds

W przypadku bezpiecznego AuthSub wymiana wymaga najpierw skonfigurowania Zend_Gdata_HttpClient i ustawienia klucza prywatnego RSA za pomocą setAuthSubPrivateKeyFile():

require_once 'Zend/Loader.php';
Zend_Loader::loadClass('Zend_Gdata_AuthSub');
Zend_Loader::loadClass('Zend_Gdata_Calendar');

$client = new Zend_Gdata_HttpClient();
$client->setAuthSubPrivateKeyFile('/path/to/myrsakey.pem', null, true);
$sessionToken = Zend_Gdata_AuthSub::getAuthSubSessionToken($singleUseToken, $client);

$calendarService = new Zend_Gdata_Calendar($client, 'google-ExampleApp-v1.0');
$calendarService->setAuthSubToken($sessionToken);

// ready to interact with Calendar feeds

Python

import gdata.calendar
import gdata.calendar.service

calendar_service = gdata.calendar.service.CalendarService()
calendar_service.UpgradeToSessionToken(single_use_token)  # calls gdata.service.SetAuthSubToken() for you

# ready to interact with Calendar feeds

Uwaga: proces jest taki sam w przypadku bezpiecznego AuthSub, o ile do wyodrębnienia jednorazowego tokena użyto gdata.auth.extract_auth_sub_token_from_url(url, rsa_key=rsa_key).

Uwaga: w przypadku bezpiecznego AuthSub klucz prywatny nie jest przesyłany przez sieć. Biblioteki klienta wysyłają unikalny podpis wygenerowany przez podpisanie żądania kluczem, a nie sam klucz.

Używanie tokena sesji

Token sesji możesz wykorzystać do uwierzytelniania żądań kierowanych do serwera, umieszczając go w nagłówku Authorization, zgodnie z opisem w dokumentacji AuthSub.

Po ustawieniu tokena sesji możesz używać standardowych wywołań biblioteki klienta interfejsów Google Data API do interakcji z usługą, nie musząc się martwić o token. Szczegółowe informacje znajdziesz w dokumentacji biblioteki klienta i przewodniku dla deweloperów Google Data API dotyczącym usługi i języka, z których korzystasz.

Pobieranie informacji o tokenie sesji

Jeśli chcesz sprawdzić, czy klient i serwer zgadzają się co do parametrów tokena, możesz przekazać token do funkcji obsługi AuthSubTokenInfo, która zwraca zestaw par nazwa-wartość zawierających informacje o tokenie.

Java

Map<String, String> tokenInfo = AuthSubUtil.getTokenInfo(sessionToken, null);

Jeśli używasz bezpiecznej autoryzacji AuthSub, przekaż klucz prywatny RSA:

Map<String, String> tokenInfo = AuthSubUtil.getTokenInfo(sessionToken, privateKey);

.NET

Dictionary<String, String> tokenInfo = AuthSubUtil.GetTokenInfo(sessionToken, null);

Jeśli używasz bezpiecznej autoryzacji AuthSub, przekaż klucz prywatny RSA:

Dictionary<String, String> tokenInfo = AuthSubUtil.GetTokenInfo(sessionToken, privateKey);

PHP

$tokenInfo = Zend_Gdata_AuthSub::getAuthSubTokenInfo($sessionToken);

Jeśli używasz bezpiecznego AuthSub, przekaż swój Zend_Gdata_HttpClient, aby żądanie zostało podpisane Twoim kluczem prywatnym RSA:

$tokenInfo = Zend_Gdata_AuthSub::getAuthSubTokenInfo($sessionToken, $client);

Python

token_info = calendar_service.AuthSubTokenInfo()

Unieważnianie tokena sesji

Tokeny sesji AuthSub nie wygasają. Klient może przechowywać token sesji tak długo, jak jest to potrzebne.

Gdy klient skończy korzystać z tokena sesji, może go cofnąć za pomocą modułu obsługi AuthSubRevokeToken, zgodnie z opisem w dokumentacji AuthSub.

Jeśli na przykład chcesz zarządzać tokenami w tradycyjny sposób, podobny do sesji, klient może uzyskać token na początku sesji użytkownika i unieważnić go na jej końcu.

Aby cofnąć token, użyj w każdej bibliotece klienta tych elementów:

Java

AuthSubUtil.revokeToken(sessionToken, null);

Jeśli używasz bezpiecznej autoryzacji AuthSub, przekaż klucz prywatny RSA:

AuthSubUtil.revokeToken(sessionToken, privateKey);

.NET

AuthSubUtil.revokeToken(sessionToken, null);

Jeśli używasz bezpiecznej autoryzacji AuthSub, przekaż klucz prywatny RSA:

AuthSubUtil.revokeToken(sessionToken, privateKey);

PHP

$wasRevoked = Zend_Gdata_AuthSub::AuthSubRevokeToken($sessionToken);

Jeśli używasz bezpiecznego AuthSub, przekaż swój Zend_Gdata_HttpClient, aby żądanie zostało podpisane Twoim kluczem prywatnym RSA:

$wasRevoked = Zend_Gdata_AuthSub::AuthSubRevokeToken($sessionToken, $client);

Python

calendar_service.RevokeAuthSubToken()

Dodatkowe materiały i przykłady

• Przykłady AuthSub na blogu z wskazówkami dotyczącymi interfejsu Google Data API
• Biblioteka klienta Python – przykład AuthSub
• Biblioteka klienta Java – przykład AuthSub
• Artykuł: Korzystanie z AuthSub w bibliotece klienta .NET
• Artykuł: Uwierzytelnianie „AuthSub” za pomocą biblioteki klienta JavaScript

Powrót do góry

Generowanie podpisanego samodzielnie klucza prywatnego i certyfikatu publicznego do użycia z bezpiecznym AuthSub

Klucz prywatny służy do generowania podpisu, który musi być dołączony do każdego żądania. Klucz publiczny osadzony w certyfikacie jest używany przez Google do weryfikacji podpisu. Klucz publiczny musi być 1024-bitowym kluczem RSA zakodowanym w certyfikacie X.509 w formacie PEM. Certyfikat należy przesłać do Google w momencie rejestracji.

W sekcjach poniżej znajdziesz przykłady generowania kluczy i certyfikatów za pomocą 2 narzędzi: narzędzia OpenSSL i narzędzia keytool w Javie.

Te przykłady nie są specyficzne dla interfejsów Google Data API. Możesz używać tych samych narzędzi do generowania kluczy w dowolnym celu.

W przykładach założono, że Twoja firma nazywa się My_Company i ma siedzibę w Mountain View w Kalifornii w Stanach Zjednoczonych, a jej nazwa domeny to example.com.

Generowanie kluczy za pomocą OpenSSL

Aby utworzyć parę kluczy RSA i odpowiadający jej certyfikat, możesz użyć tego polecenia:

# Generate the RSA keys and certificate
openssl req -x509 -nodes -days 365 -newkey rsa:1024 -sha1 -subj \
  '/C=US/ST=CA/L=Mountain View/CN=www.example.com' -keyout \
  myrsakey.pem -out /tmp/myrsacert.pem

Ostrzeżenie: uwzględnienie parametru -nodes powoduje utworzenie klucza prywatnego bez hasła, które by go chroniło. Jednak ze względów bezpieczeństwa warto pominąć ten parametr.

Parametr -sha1 określa, że klucz będzie używany do generowania podpisów SHA1.

Parametr -subj określa tożsamość aplikacji, którą reprezentuje certyfikat.

Parametr -keyout określa plik, który będzie zawierać klucze. Ten plik zawiera informacje poufne, dlatego należy go chronić i nie udostępniać nikomu.

Parametr -out określa plik, który będzie zawierać certyfikat w formacie PEM (można go przesłać do Google podczas rejestracji).

Generowanie kluczy dla klienta .NET

Platforma .NET nie rozpoznaje kluczy ani certyfikatów zapisanych w formacie PEM. Dlatego po utworzeniu pliku .pem musisz wykonać dodatkowy krok:

openssl pkcs12 -export -in test_cert.pem -inkey myrsacert.pem -out myrsacert.pfx -name "Testing Certificate"

Ten krok generuje plik PFX z klucza prywatnego i certyfikatu. Ten plik można zaimportować do biblioteki klienta .NET, aby cyfrowo podpisywać żądania wysyłane do interfejsów Google Data API.

Generowanie kluczy dla klienta Java

Klient Java akceptuje klucze prywatne w formacie PKCS#8. Po wygenerowaniu klucza lub certyfikatu zgodnie z powyższymi instrukcjami utwórz plik .pk8 z wygenerowanego pliku .pem:

openssl pkcs8 -in myrsakey.pem -topk8 -nocrypt -out myrsakey.pk8

Możesz też użyć magazynu kluczy Java i narzędzia keytool, aby utworzyć parę kluczy RSA i odpowiedni certyfikat. Użyj tego polecenia:

# Generate the RSA keys and certificate
keytool -genkey -v -alias Example -keystore ./Example.jks\
  -keyalg RSA -sigalg SHA1withRSA\
  -dname "CN=www.example.com, OU=Engineering, O=My_Company, L=Mountain  View, ST=CA, C=US"\
  -storepass changeme -keypass changeme

Ostrzeżenie: „changeme” to słabe hasło. To tylko przykład.

Parametr -dname określa tożsamość aplikacji, którą reprezentuje certyfikat. Parametr -storepass określa hasło do ochrony magazynu kluczy. Parametr -keypass określa hasło do ochrony klucza prywatnego.

Aby zapisać certyfikat w pliku, którego można użyć w narzędziu ManageDomains, użyj tego polecenia:

# Output the public certificate to a file
keytool -export -rfc -keystore ./Example.jks -storepass changeme \
  -alias Example -file mycert.pem

Powrót do góry