OpenID Connect

OAuth 2.0 API Google dapat digunakan untuk autentikasi dan otorisasi. Dokumen ini menjelaskan implementasi OAuth 2.0 kami untuk autentikasi, yang sesuai dengan spesifikasi OpenID Connect, dan Bersertifikat OpenID. Dokumentasi yang ditemukan di Menggunakan OAuth 2.0 untuk Mengakses Google API juga berlaku untuk layanan ini. Jika Anda ingin mempelajari protokol ini secara interaktif, sebaiknya gunakan Google OAuth 2.0 Playground. Untuk mendapatkan bantuan di Stack Overflow, beri tag pada pertanyaan Anda dengan 'google-oauth'.

Menyiapkan OAuth 2.0

Sebelum aplikasi Anda dapat menggunakan sistem autentikasi OAuth 2.0 Google untuk login pengguna, Anda harus menyiapkan project di Google API Console untuk mendapatkan kredensial OAuth 2.0, menetapkan URI alihan, dan (opsional) menyesuaikan informasi branding yang dilihat pengguna di layar izin pengguna. Anda juga dapat menggunakan API Console untuk membuat akun layanan, mengaktifkan penagihan, menyiapkan pemfilteran, dan melakukan tugas lainnya. Untuk detail selengkapnya, lihat Bantuan Google API Console.

Mendapatkan kredensial OAuth 2.0

Anda memerlukan kredensial OAuth 2.0, termasuk client ID dan rahasia klien, untuk mengautentikasi pengguna dan mendapatkan akses ke API Google.

Untuk melihat ID klien dan rahasia klien untuk kredensial OAuth 2.0 yang diberikan, klik teks berikut: Pilih kredensial . Di jendela yang terbuka, pilih proyek Anda dan kredensial yang Anda inginkan, lalu klik Lihat .

Atau, lihat ID klien Anda dan rahasia klien dari halaman Kredensial di API Console :

1. Go to the Credentials page.
2. Klik nama kredensial Anda atau ikon pensil ( create ). ID dan rahasia klien Anda ada di bagian atas halaman.

Menetapkan URI pengalihan

URI pengalihan yang Anda tetapkan di API Console menentukan tempat Google mengirim respons ke permintaan autentikasi Anda.

Untuk membuat, melihat, atau mengedit URI redirect untuk kredensial OAuth 2.0 yang diberikan, lakukan hal berikut:

1. Go to the Credentials page.
2. Di bagian OAuth 2.0 klien ID halaman, klik kredensial.
3. Lihat atau edit URI pengalihan.

Jika tidak ada bagian ID klien OAuth 2.0 di halaman Kredensial, maka proyek Anda tidak memiliki kredensial OAuth. Untuk membuatnya, klik Buat kredensial .

Menyesuaikan layar izin pengguna

Untuk pengguna Anda, pengalaman autentikasi OAuth 2.0 mencakup layar izin yang menjelaskan informasi yang dirilis pengguna dan persyaratan yang berlaku. Misalnya, saat pengguna login, mereka mungkin diminta untuk memberi aplikasi Anda akses ke alamat email dan informasi akun dasar mereka. Anda meminta akses ke informasi ini menggunakan parameter scope, yang disertakan aplikasi Anda dalam permintaan autentikasi. Anda juga dapat menggunakan cakupan untuk meminta akses ke Google API lainnya.

Layar izin pengguna juga menampilkan informasi branding seperti nama produk, logo, dan URL halaman beranda Anda. Anda mengontrol informasi branding di API Console.

Untuk mengaktifkan layar persetujuan proyek Anda:

1. Buka Consent Screen page di Google API Console .
2. If prompted, select a project, or create a new one.
3. Isi formulir dan klik Simpan .

Dialog izin berikut menunjukkan apa yang akan dilihat pengguna saat kombinasi cakupan OAuth 2.0 dan Google Drive ada dalam permintaan. (Dialog umum ini dibuat menggunakan Google OAuth 2.0 Playground, sehingga tidak menyertakan informasi branding yang akan ditetapkan di API Console.)

Mengakses layanan

Google dan pihak ketiga menyediakan library yang dapat Anda gunakan untuk menangani banyak detail penerapan autentikasi pengguna dan mendapatkan akses ke Google API. Contohnya mencakup Layanan Identitas Google dan library klien Google, yang tersedia untuk berbagai platform.

Jika Anda memilih untuk tidak menggunakan library, ikuti petunjuk di bagian lain dokumen ini, yang menjelaskan alur permintaan HTTP yang mendasari library yang tersedia.

Mengautentikasi pengguna

Mengautentikasi pengguna melibatkan perolehan token ID dan memvalidasinya. Token ID adalah fitur standar dari OpenID Connect yang dirancang untuk digunakan dalam membagikan pernyataan identitas di Internet.

Pendekatan yang paling umum digunakan untuk mengautentikasi pengguna dan mendapatkan token ID disebut alur "server" dan alur "implisit". Alur server memungkinkan server back-end aplikasi memverifikasi identitas orang yang menggunakan browser atau perangkat seluler. Alur implisit digunakan saat aplikasi sisi klien (biasanya aplikasi JavaScript yang berjalan di browser) perlu mengakses API secara langsung, bukan melalui server backend-nya.

Dokumen ini menjelaskan cara melakukan alur server untuk mengautentikasi pengguna. Alur implisit jauh lebih rumit karena risiko keamanan dalam menangani dan menggunakan token di sisi klien. Jika Anda perlu menerapkan alur implisit, sebaiknya gunakan Layanan Identitas Google.

Alur server

Pastikan Anda menyiapkan aplikasi di API Console agar dapat menggunakan protokol ini dan mengautentikasi pengguna. Saat pengguna mencoba login dengan Google, Anda harus:

1. Membuat token status anti-pemalsuan
2. Mengirim permintaan autentikasi ke Google
3. Mengonfirmasi token status anti-pemalsuan
4. Menukar code dengan token akses dan token ID
5. Mendapatkan informasi pengguna dari token ID
6. Autentikasi pengguna

1. Membuat token status anti-pemalsuan

Anda harus melindungi keamanan pengguna dengan mencegah serangan pemalsuan permintaan. Langkah pertama adalah membuat token sesi unik yang menyimpan status antara aplikasi Anda dan klien pengguna. Kemudian, Anda akan mencocokkan token sesi unik ini dengan respons autentikasi yang ditampilkan oleh layanan Login OAuth Google untuk memverifikasi bahwa pengguna yang membuat permintaan, bukan penyerang berbahaya. Token ini sering disebut sebagai token pembuatan pesan palsu permintaan lintas situs (CSRF).

Salah satu pilihan yang baik untuk token status adalah string yang terdiri dari 30 karakter atau lebih yang dibuat menggunakan generator angka acak berkualitas tinggi. Yang lainnya adalah hash yang dihasilkan dengan menandatangani beberapa variabel status sesi dengan kunci yang dirahasiakan di backend Anda.

Kode berikut menunjukkan cara membuat token sesi unik.

// 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. Mengirim permintaan autentikasi ke Google

Langkah berikutnya adalah membentuk permintaan GET HTTPS dengan parameter URI yang sesuai. Perhatikan penggunaan HTTPS, bukan HTTP, di semua langkah proses ini; koneksi HTTP menolak. Anda harus mengambil URI dasar dari Dokumen penemuan menggunakan nilai metadata authorization_endpoint. Diskusi berikut mengasumsikan bahwa URI dasar adalah https://accounts.google.com/o/oauth2/v2/auth.

Untuk permintaan dasar, tentukan parameter berikut:

• client_id, yang Anda peroleh dari API Console Credentials page .
• response_type, yang dalam permintaan alur kode otorisasi dasar harus code. (Baca selengkapnya di response_type.)
• scope, yang dalam permintaan dasar harus berupa openid email. (Baca selengkapnya di scope.)
• redirect_uri harus berupa endpoint HTTP di server Anda yang akan menerima respons dari Google. Nilai harus sama persis dengan salah satu URI alihan yang diotorisasi untuk klien OAuth 2.0, yang Anda konfigurasikan di API Console Credentials page. Jika nilai ini tidak cocok dengan URI yang diotorisasi, permintaan akan gagal dengan error redirect_uri_mismatch.
• state harus menyertakan nilai token sesi unik anti-pemalsuan, serta informasi lain yang diperlukan untuk memulihkan konteks saat pengguna kembali ke aplikasi Anda, misalnya, URL awal. (Baca selengkapnya di state.)
• nonce adalah nilai acak yang dihasilkan oleh aplikasi Anda yang mengaktifkan perlindungan replay jika ada.
• login_hint dapat berupa alamat email pengguna atau string sub, yang setara dengan ID Google pengguna. Jika Anda tidak memberikan login_hint dan pengguna saat ini login, layar izin akan menyertakan permintaan persetujuan untuk merilis alamat email pengguna ke aplikasi Anda. (Baca selengkapnya di login_hint.)
• Gunakan parameter hd untuk mengoptimalkan alur OpenID Connect bagi pengguna domain tertentu yang terkait dengan organisasi Google Workspace atau Cloud (baca selengkapnya di hd).

Berikut adalah contoh URI autentikasi OpenID Connect lengkap, dengan baris baru dan spasi agar lebih mudah dibaca:

https://accounts.google.com/o/oauth2/v2/auth?
 response_type=code&
 client_id=424911365001.apps.googleusercontent.com&
 scope=openid%20email&
 redirect_uri=https%3A//oauth2.example.com/code&
 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

Pengguna diwajibkan untuk memberikan izin jika aplikasi Anda meminta informasi baru tentang mereka, atau jika aplikasi Anda meminta akses akun yang sebelumnya belum disetujui oleh mereka.

3. Mengonfirmasi token status anti-pemalsuan

Respons dikirim ke redirect_uri yang Anda tentukan dalam permintaan. Semua respons ditampilkan dalam string kueri, seperti yang ditunjukkan di bawah ini:

https://oauth2.example.com/code?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

Di server, Anda harus mengonfirmasi bahwa state yang diterima dari Google cocok dengan token sesi yang Anda buat di Langkah 1. Verifikasi bolak-balik ini membantu memastikan bahwa pengguna, bukan skrip berbahaya, yang membuat permintaan.

Kode berikut menunjukkan konfirmasi token sesi yang Anda buat di Langkah 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. Menukar code dengan token akses dan token ID

Respons menyertakan parameter code, kode otorisasi satu kali yang dapat ditukarkan oleh server Anda dengan token akses dan token ID. Server Anda melakukan pertukaran ini dengan mengirim permintaan POST HTTPS. Permintaan POST dikirim ke endpoint token, yang harus Anda ambil dari dokumen Discovery menggunakan nilai metadata token_endpoint. Diskusi berikut mengasumsikan endpoint adalah https://oauth2.googleapis.com/token. Permintaan harus menyertakan parameter berikut dalam isi POST:

Permintaan yang sebenarnya mungkin terlihat seperti contoh berikut:

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//oauth2.example.com/code&
grant_type=authorization_code

Respons yang berhasil untuk permintaan ini berisi kolom berikut dalam array JSON:

5. Mendapatkan informasi pengguna dari token ID

Token ID adalah JWT (Token Web JSON), yaitu objek JSON yang dienkode Base64 dan ditandatangani secara kriptografis. Biasanya, Anda harus memvalidasi token ID sebelum menggunakannya, tetapi karena Anda berkomunikasi langsung dengan Google melalui saluran HTTPS bebas perantara dan menggunakan secret klien untuk mengautentikasi diri Anda ke Google, Anda dapat yakin bahwa token yang Anda terima benar-benar berasal dari Google dan valid. Jika server Anda meneruskan token ID ke komponen aplikasi lainnya, komponen lain harus memvalidasi token sebelum menggunakannya.

Karena sebagian besar library API menggabungkan validasi dengan tugas mendekode nilai yang dienkode base64url dan mengurai JSON di dalamnya, Anda mungkin akan memvalidasi token saat mengakses klaim dalam token ID.

Payload token ID

Token ID adalah objek JSON yang berisi kumpulan pasangan nama/nilai. Berikut adalah contoh, yang diformat agar mudah dibaca:

{
  "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"
}

Token ID Google dapat berisi kolom berikut (dikenal sebagai klaim):

6. Mengautentikasi pengguna

Setelah mendapatkan informasi pengguna dari token ID, Anda harus membuat kueri database pengguna aplikasi. Jika pengguna sudah ada di database, Anda harus memulai sesi aplikasi untuk pengguna tersebut jika semua persyaratan login terpenuhi oleh respons Google API.

Jika pengguna tidak ada dalam database pengguna, Anda harus mengalihkan pengguna ke alur pendaftaran pengguna baru. Anda mungkin dapat mendaftarkan pengguna secara otomatis berdasarkan informasi yang Anda terima dari Google, atau setidaknya Anda dapat mengisi otomatis banyak kolom yang Anda perlukan di formulir pendaftaran. Selain informasi dalam token ID, Anda bisa mendapatkan informasi profil pengguna tambahan di endpoint profil pengguna kami.

Topik lanjutan

Bagian berikut menjelaskan Google OAuth 2.0 API secara lebih mendetail. Informasi ini ditujukan bagi developer dengan persyaratan lanjutan seputar autentikasi dan otorisasi.

Akses ke Google API lainnya

Salah satu keuntungan menggunakan OAuth 2.0 untuk autentikasi adalah aplikasi Anda dapat mendapatkan izin untuk menggunakan Google API lainnya atas nama pengguna (seperti YouTube, Google Drive, Kalender, atau Kontak) secara bersamaan saat Anda mengautentikasi pengguna. Untuk melakukannya, sertakan cakupan lain yang Anda perlukan dalam permintaan autentikasi yang Anda kirim ke Google. Misalnya, untuk menambahkan grup usia pengguna ke permintaan autentikasi Anda, teruskan parameter cakupan openid email https://www.googleapis.com/auth/profile.agerange.read. Pengguna diminta dengan tepat di layar izin. Token akses yang Anda terima kembali dari Google memungkinkan Anda mengakses semua API yang terkait dengan cakupan akses yang Anda minta dan diberikan.

Token refresh

Dalam permintaan akses API, Anda dapat meminta token refresh untuk ditampilkan selama pertukaran code. Token refresh memberi aplikasi Anda akses berkelanjutan ke Google API saat pengguna tidak ada di aplikasi Anda. Untuk meminta token refresh, tambahkan parameter access_type ke offline dalam permintaan autentikasi Anda.

Pertimbangan:

• Pastikan untuk menyimpan token refresh dengan aman dan permanen, karena Anda hanya dapat memperoleh token refresh saat pertama kali melakukan alur pertukaran kode.
• Ada batasan jumlah token refresh yang dikeluarkan: satu batasan per kombinasi klien/pengguna, dan satu lagi per pengguna di semua klien. Jika aplikasi Anda meminta terlalu banyak token refresh, aplikasi tersebut mungkin akan mengalami batas ini, dan jika demikian, token refresh lama akan berhenti berfungsi.

Untuk informasi selengkapnya, lihat Memuat ulang token akses (akses offline).

Meminta izin ulang

Anda dapat meminta pengguna untuk memberikan otorisasi ulang ke aplikasi dengan menetapkan parameter prompt ke consent dalam permintaan autentikasi. Jika prompt=consent disertakan, layar izin akan ditampilkan setiap kali aplikasi Anda meminta otorisasi cakupan akses, meskipun semua cakupan sebelumnya telah diberikan ke project Google API Anda. Oleh karena itu, sertakan prompt=consent hanya jika diperlukan.

Untuk mengetahui informasi selengkapnya tentang parameter prompt, lihat prompt dalam tabel Parameter URI autentikasi.

Parameter URI autentikasi

Tabel berikut memberikan deskripsi yang lebih lengkap tentang parameter yang diterima oleh API autentikasi OAuth 2.0 Google.

Memvalidasi token ID

Anda harus memvalidasi semua token ID di server, kecuali jika Anda tahu bahwa token tersebut berasal langsung dari Google. Misalnya, server Anda harus memverifikasi keaslian token ID apa pun yang diterima dari aplikasi klien Anda.

Berikut adalah situasi umum saat Anda mungkin mengirim token ID ke server:

• Mengirim token ID dengan permintaan yang perlu diautentikasi. Token ID memberi tahu Anda pengguna tertentu yang membuat permintaan dan klien mana yang diberi token ID tersebut.

Token ID bersifat sensitif dan dapat disalahgunakan jika disadap. Anda harus memastikan bahwa token ini ditangani dengan aman dengan mengirimkannya hanya melalui HTTPS dan hanya melalui data POST atau dalam header permintaan. Jika menyimpan token ID di server, Anda juga harus menyimpannya dengan aman.

Satu hal yang membuat token ID berguna adalah fakta bahwa Anda dapat meneruskannya ke berbagai komponen aplikasi. Komponen ini dapat menggunakan token ID sebagai mekanisme autentikasi ringan yang mengautentikasi aplikasi dan pengguna. Namun, sebelum dapat menggunakan informasi dalam token ID atau mengandalkannya sebagai pernyataan bahwa pengguna telah diautentikasi, Anda harus memvalidasinya.

Validasi token ID memerlukan beberapa langkah:

1. Verifikasi bahwa token ID ditandatangani dengan benar oleh penerbit. Token yang diterbitkan Google ditandatangani menggunakan salah satu sertifikat yang ditemukan di URI yang ditentukan dalam nilai metadata jwks_uri dokumen Discovery.
2. Verifikasi bahwa nilai klaim iss dalam token ID sama dengan https://accounts.google.com atau accounts.google.com.
3. Pastikan nilai klaim aud dalam token ID sama dengan client ID aplikasi Anda.
4. Pastikan waktu habis masa berlaku (klaim exp) token ID belum lewat.
5. Jika Anda menentukan nilai parameter hd dalam permintaan, pastikan bahwa token ID memiliki klaim hd yang cocok dengan domain yang diterima dan terkait dengan organisasi Google Cloud.

Langkah 2 hingga 5 hanya melibatkan perbandingan string dan tanggal yang cukup mudah, jadi kita tidak akan menjelaskannya di sini.

Langkah pertama lebih kompleks, dan melibatkan pemeriksaan tanda tangan kriptografis. Untuk tujuan proses debug, Anda dapat menggunakan endpoint tokeninfo Google untuk dibandingkan dengan pemrosesan lokal yang diterapkan di server atau perangkat Anda. Misalkan nilai token ID Anda adalah XYZ123. Kemudian, Anda akan mendereferensikan URI https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123. Jika tanda tangan token valid, responsnya akan berupa payload JWT dalam bentuk objek JSON yang didekode.

Endpoint tokeninfo berguna untuk proses debug, tetapi untuk tujuan produksi, ambil kunci publik Google dari endpoint kunci dan lakukan validasi secara lokal. Anda harus mengambil URI kunci dari dokumen Discovery menggunakan nilai metadata jwks_uri. Permintaan ke endpoint proses debug dapat dibatasi atau mengalami error yang terputus-putus.

Karena Google jarang mengubah kunci publiknya, Anda dapat meng-cache-nya menggunakan perintah cache respons HTTP dan, dalam sebagian besar kasus, melakukan validasi lokal jauh lebih efisien daripada menggunakan endpoint tokeninfo. Validasi ini memerlukan pengambilan dan penguraian sertifikat, serta melakukan panggilan kriptografis yang sesuai untuk memeriksa tanda tangan. Untungnya, ada library yang di-debug dengan baik yang tersedia dalam berbagai bahasa untuk melakukannya (lihat jwt.io).

Mendapatkan informasi profil pengguna

Untuk mendapatkan informasi profil tambahan tentang pengguna, Anda dapat menggunakan token akses (yang diterima aplikasi Anda selama alur autentikasi) dan standar OpenID Connect:

1. Agar sesuai dengan OpenID, Anda harus menyertakan nilai cakupan openid profile dalam permintaan autentikasi.

   Jika ingin alamat email pengguna disertakan, Anda dapat menentukan nilai cakupan tambahan email. Untuk menentukan profile dan email, Anda dapat menyertakan parameter berikut dalam URI permintaan autentikasi:

   scope=openid%20profile%20email

2. Tambahkan token akses Anda ke header otorisasi dan buat permintaan GET HTTPS ke endpoint userinfo, yang harus Anda ambil dari dokumen Discovery menggunakan nilai metadata userinfo_endpoint. Respons userinfo menyertakan informasi tentang pengguna, seperti yang dijelaskan dalam OpenID Connect Standard Claims dan nilai metadata claims_supported dari dokumen Discovery. Pengguna atau organisasi mereka dapat memilih untuk memberikan atau menyembunyikan kolom tertentu, sehingga Anda mungkin tidak mendapatkan informasi untuk setiap kolom untuk cakupan akses yang diotorisasi.

Dokumen Discovery

Protokol OpenID Connect memerlukan penggunaan beberapa endpoint untuk mengautentikasi pengguna, dan untuk meminta resource termasuk token, informasi pengguna, dan kunci publik.

Untuk menyederhanakan implementasi dan meningkatkan fleksibilitas, OpenID Connect memungkinkan penggunaan "Dokumen penemuan", dokumen JSON yang ditemukan di lokasi terkenal yang berisi pasangan nilai kunci yang memberikan detail tentang konfigurasi penyedia OpenID Connect, termasuk URI endpoint otorisasi, token, pencabutan, userinfo, dan kunci publik. Dokumen Discovery untuk layanan OpenID Connect Google dapat diambil dari:

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

Untuk menggunakan layanan OpenID Connect Google, Anda harus melakukan hard code URI dokumen Discovery (https://accounts.google.com/.well-known/openid-configuration) ke dalam aplikasi. Aplikasi Anda mengambil dokumen, menerapkan aturan penyimpanan dalam respons, lalu mengambil URI endpoint darinya sesuai kebutuhan. Misalnya, untuk mengautentikasi pengguna, kode Anda akan mengambil nilai metadata authorization_endpoint (https://accounts.google.com/o/oauth2/v2/auth dalam contoh di bawah) sebagai URI dasar untuk permintaan autentikasi yang dikirim ke Google.

Berikut adalah contoh dokumen tersebut; nama kolom adalah nama yang ditentukan dalam OpenID Connect Discovery 1.0 (lihat dokumen tersebut untuk mengetahui artinya). Nilai ini hanya bersifat ilustrasi dan dapat berubah, meskipun disalin dari versi terbaru dokumen Google Penemuan yang sebenarnya:

{
  "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"
  ]
}

Anda mungkin dapat menghindari perjalanan bolak-balik HTTP dengan meng-cache nilai dari dokumen Discovery. Header caching HTTP standar digunakan dan harus dipatuhi.

Library klien

Library klien berikut mempermudah penerapan OAuth 2.0 dengan berintegrasi dengan framework populer:

• Library Klien Google API untuk Java
• Library Klien Google API untuk Python
• Library Klien Google API untuk .NET
• Library Klien Google API untuk Ruby
• Library Klien Google API untuk PHP
• Library OAuth 2.0 untuk Google Web Toolkit
• Pengontrol OAuth 2.0 Google Toolbox for Mac

Kepatuhan OpenID Connect

Sistem autentikasi OAuth 2.0 Google mendukung fitur yang diperlukan dari spesifikasi OpenID Connect Core. Setiap klien yang dirancang untuk berfungsi dengan OpenID Connect harus berinteraksi dengan layanan ini (kecuali Objek Permintaan OpenID).