OpenID Connect

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

Menyiapkan OAuth 2.0

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

Mendapatkan kredensial OAuth 2.0

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

To view the client ID and client secret for a given OAuth 2.0 credential, click the following text: Select credential. In the window that opens, choose your project and the credential you want, then click View.

Or, view your client ID and client secret from the in :

  1. Go to the Credentials page.
  2. Click the name of your client or the edit () icon. Your client ID and secret are at the top of the page.

Menetapkan URI pengalihan

URI pengalihan yang Anda tetapkan di menentukan tujuan Google mengirimkan respons ke permintaan autentikasi Anda.

To create, view, or edit the redirect URIs for a given OAuth 2.0 credential, do the following:

  1. Go to the Credentials page.
  2. Click on the client.
  3. View or edit the redirect URIs.

If there is no listed client in the Clients page, then your project has no OAuth credentials. To create one, click Create client.

Menyesuaikan layar izin pengguna

Bagi pengguna Anda, pengalaman autentikasi OAuth 2.0 mencakup layar izin yang menjelaskan informasi yang dilepaskan pengguna dan persyaratan yang berlaku. Misalnya, saat pengguna login, mereka mungkin diminta untuk memberikan akses aplikasi Anda ke alamat email dan informasi akun dasar mereka. Anda meminta akses ke informasi ini menggunakan parameter scope, yang disertakan aplikasi Anda dalam permintaan autentikasinya. 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 beranda. Anda mengontrol informasi branding di .

To enable your project's consent screen:

  1. Open the in the .
  2. If prompted, select a project, or create a new one.
  3. Fill out the form and click Save.

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 .)

Contoh halaman izin
Gambar 1. Screenshot halaman izin

Mengakses layanan

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

Jika Anda memilih untuk tidak menggunakan library, ikuti petunjuk di bagian selanjutnya dalam 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 OpenID Connect yang dirancang untuk digunakan dalam berbagi 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 backend 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 menggunakan 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 agar dapat menggunakan protokol ini dan mengautentikasi pengguna Anda. Saat pengguna mencoba login dengan Google, Anda harus:

  1. Membuat token status anti-pemalsuan
  2. Mengirim permintaan autentikasi ke Google
  3. Konfirmasi token status anti-pemalsuan
  4. Menukarkan code dengan token akses dan token ID
  5. Mendapatkan informasi pengguna dari token ID
  6. Mengautentikasi 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. Selanjutnya, Anda mencocokkan token sesi unik ini dengan respons autentikasi yang ditampilkan oleh layanan Login OAuth Google untuk memverifikasi bahwa pengguna membuat permintaan dan bukan penyerang berbahaya. Token ini sering disebut sebagai token pemalsuan permintaan lintas situs (CSRF).

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

Kode berikut menunjukkan cara membuat token sesi unik.

PHP

Anda harus mendownload library klien Google API untuk PHP untuk menggunakan contoh ini.

// 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
));

Java

Anda harus mendownload library klien Google API untuk Java untuk menggunakan contoh ini.

// 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);

Python

Anda harus mendownload library klien Google API untuk Python guna menggunakan contoh ini.

# 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 membuat permintaan GET HTTPS dengan parameter URI yang sesuai. Perhatikan penggunaan HTTPS, bukan HTTP, di semua langkah proses ini; koneksi HTTP ditolak. Anda harus mengambil URI dasar dari Dokumen penemuan menggunakan nilai metadata authorization_endpoint. Diskusi berikut mengasumsikan URI dasar adalah https://accounts.google.com/o/oauth2/v2/auth.

Untuk permintaan dasar, tentukan parameter berikut:

  • client_id, yang Anda dapatkan dari .
  • response_type, yang dalam permintaan alur kode otorisasi dasar harus berupa 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 pengalihan yang diberi otorisasi untuk klien OAuth 2.0, yang Anda konfigurasi di Credentials page. Jika nilai ini tidak cocok dengan URI yang sah, 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 dibuat oleh aplikasi Anda yang memungkinkan perlindungan serangan 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 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 di domain tertentu yang terkait dengan organisasi Google Workspace atau Cloud (baca selengkapnya di hd).

Berikut adalah contoh URI autentikasi OpenID Connect lengkap, dengan jeda baris dan spasi agar 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 belum mereka setujui sebelumnya.

3. Mengonfirmasi token status anti-pemalsuan

Respons dikirim ke redirect_uri yang Anda tentukan dalam permintaan. Semua respons ditampilkan dalam string kueri:

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 pulang pergi ini membantu memverifikasi bahwa pengguna, bukan skrip berbahaya, yang membuat permintaan.

Kode berikut menunjukkan cara mengonfirmasi token sesi yang Anda buat di Langkah 1:

PHP

Anda harus mendownload library klien Google API untuk PHP untuk menggunakan contoh ini.

// 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);
}

Java

Anda harus mendownload library klien Google API untuk Java untuk menggunakan contoh ini.

// 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.");
}

Python

Anda harus mendownload library klien Google API untuk Python guna menggunakan contoh ini.

# 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. Menukarkan code dengan token akses dan token ID

Respons mencakup parameter code, kode otorisasi sekali pakai yang dapat ditukar server Anda dengan token akses dan token ID. Server Anda melakukan pertukaran ini dengan mengirim permintaan HTTPS POST. Permintaan POST dikirim ke endpoint token, yang harus Anda ambil dari Dokumen penemuan menggunakan nilai metadata token_endpoint. Diskusi berikut mengasumsikan bahwa endpoint-nya adalah https://oauth2.googleapis.com/token. Permintaan harus menyertakan parameter berikut dalam isi POST:

Kolom
code Kode otorisasi yang ditampilkan dari permintaan awal.
client_id ID klien yang Anda dapatkan dari , seperti yang dijelaskan dalam Mendapatkan kredensial OAuth 2.0.
client_secret Rahasia klien yang Anda dapatkan dari , seperti yang dijelaskan dalam Mendapatkan kredensial OAuth 2.0.
redirect_uri URI pengalihan yang sah untuk client_id tertentu yang ditentukan dalam , seperti yang dijelaskan dalam Menetapkan URI pengalihan.
grant_type Kolom ini harus berisi nilai authorization_code, seperti yang ditentukan dalam spesifikasi OAuth 2.0.

Permintaan 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 terhadap permintaan ini berisi kolom berikut dalam array JSON:

Kolom
access_token Token yang dapat dikirim ke Google API.
expires_in Masa aktif token akses yang tersisa dalam detik.
id_token JWT yang berisi informasi identitas tentang pengguna yang ditandatangani secara digital oleh Google.
scope Cakupan akses yang diberikan oleh access_token dinyatakan sebagai daftar string yang peka huruf besar/kecil dan dipisahkan spasi.
token_type Mengidentifikasi jenis token yang ditampilkan. Saat ini, kolom ini selalu memiliki nilai Bearer.
refresh_token (opsional)

Kolom ini hanya ada jika parameter access_type ditetapkan ke offline dalam permintaan autentikasi. Untuk mengetahui detailnya, lihat Token refresh.

5. Mendapatkan informasi pengguna dari token ID

Token ID adalah JWT (Token Web JSON), yaitu objek JSON berenkode Base64 yang ditandatangani secara kriptografis. Biasanya, Anda harus memvalidasi token ID sebelum menggunakannya, tetapi karena Anda berkomunikasi langsung dengan Google melalui saluran HTTPS tanpa 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 lain aplikasi Anda, sangat penting agar komponen lain tersebut 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 tetap memvalidasi token saat mengakses klaim dalam token ID.

Payload token ID

Token ID adalah objek JSON yang berisi serangkaian pasangan nama/nilai. Berikut contohnya, 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):

Klaim Tersedia Deskripsi
aud selalu Audiens yang dituju oleh token ID ini. ID ini harus berupa salah satu ID klien OAuth 2.0 aplikasi Anda.
exp selalu Waktu habis masa berlaku saat atau setelah token ID tidak boleh diterima. Direpresentasikan dalam waktu epoch Unix (detik bilangan bulat).
iat selalu Waktu penerbitan token ID. Direpresentasikan dalam waktu epoch Unix (detik bilangan bulat).
iss selalu ID Penerbit untuk Penerbit respons. Selalu https://accounts.google.com atau accounts.google.com untuk token ID Google.
sub selalu ID untuk pengguna, unik di antara semua Akun Google dan tidak pernah digunakan kembali. Akun Google dapat memiliki beberapa alamat email pada waktu yang berbeda, tetapi nilai sub tidak pernah diubah. Gunakan sub dalam aplikasi Anda sebagai kunci ID unik untuk pengguna. Panjang maksimum 255 karakter ASCII peka huruf besar/kecil.
at_hash Hash token akses. Memberikan validasi bahwa token akses terikat dengan token identitas. Jika token ID dikeluarkan dengan nilai access_token dalam alur server, klaim ini akan selalu disertakan. Klaim ini dapat digunakan sebagai mekanisme alternatif untuk melindungi dari serangan pemalsuan permintaan lintas situs, tetapi jika Anda mengikuti Langkah 1 dan Langkah 3, Anda tidak perlu memverifikasi token akses.
azp client_id presenter yang diberi otorisasi. Klaim ini hanya diperlukan jika pihak yang meminta token ID tidak sama dengan audiens token ID. Hal ini dapat terjadi di Google untuk aplikasi hybrid di mana aplikasi web dan aplikasi Android memiliki OAuth 2.0 client_id yang berbeda, tetapi menggunakan project Google API yang sama.
email Alamat email pengguna. Disediakan hanya jika Anda menyertakan cakupan email dalam permintaan Anda. Nilai klaim ini mungkin tidak unik untuk akun ini dan dapat berubah seiring waktu, oleh karena itu Anda tidak boleh menggunakan nilai ini sebagai ID utama untuk ditautkan ke catatan pengguna Anda. Anda juga tidak dapat mengandalkan domain klaim email untuk mengidentifikasi pengguna organisasi Google Workspace atau Cloud; gunakan klaim hd sebagai gantinya.
email_verified Benar jika alamat email pengguna telah diverifikasi; salah jika tidak.
family_name Nama belakang pengguna. Dapat diberikan jika klaim name ada.
given_name Nama depan pengguna. Dapat diberikan jika klaim name ada.
hd Domain yang terkait dengan organisasi Google Workspace atau Cloud pengguna. Disediakan hanya jika pengguna termasuk dalam organisasi Google Cloud. Anda harus memeriksa klaim ini saat membatasi akses ke resource hanya untuk anggota domain tertentu. Tidak adanya klaim ini menunjukkan bahwa akun tersebut bukan milik domain yang dihosting Google.
locale Bahasa lokal pengguna, yang ditampilkan oleh tag bahasa BCP 47. Dapat diberikan jika klaim name ada.
name Nama lengkap pengguna, dalam bentuk yang dapat ditampilkan. Dapat diberikan jika:
  • Cakupan permintaan menyertakan string "profile"
  • Token ID ditampilkan dari refresh token

Jika klaim name ada, Anda dapat menggunakannya untuk memperbarui catatan pengguna aplikasi Anda. Perhatikan bahwa klaim ini tidak pernah dijamin ada.

nonce Nilai nonce yang disediakan oleh aplikasi Anda dalam permintaan autentikasi. Anda harus melindungi dari serangan replay dengan menampilkan nilai ini hanya sekali.
picture URL foto profil pengguna. Dapat diberikan jika:
  • Cakupan permintaan menyertakan string "profile"
  • Token ID ditampilkan dari refresh token

Jika klaim picture ada, Anda dapat menggunakannya untuk memperbarui catatan pengguna aplikasi Anda. Perhatikan bahwa klaim ini tidak pernah dijamin ada.

profile URL halaman profil pengguna. Dapat diberikan jika:
  • Cakupan permintaan menyertakan string "profile"
  • Token ID ditampilkan dari refresh token

Jika klaim profile ada, Anda dapat menggunakannya untuk memperbarui catatan pengguna aplikasi Anda. Perhatikan bahwa klaim ini tidak pernah dijamin ada.

6. Mengautentikasi pengguna

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

Jika pengguna tidak ada di database pengguna Anda, Anda harus mengalihkan pengguna ke alur pendaftaran pengguna baru. Anda dapat mendaftarkan pengguna secara otomatis berdasarkan informasi yang Anda terima dari Google, atau setidaknya Anda dapat mengisi otomatis banyak kolom yang diperlukan dalam formulir pendaftaran Anda. 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 terkait autentikasi dan otorisasi.

Akses ke Google API lainnya

Salah satu keuntungan menggunakan OAuth 2.0 untuk autentikasi adalah aplikasi Anda dapat memperoleh izin untuk menggunakan Google API lain atas nama pengguna (seperti YouTube, Google Drive, Kalender, atau Kontak) pada saat yang sama saat Anda mengautentikasi pengguna. Untuk melakukannya, sertakan cakupan lain yang Anda butuhkan 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 akan diminta dengan tepat di layar izin. Token akses yang Anda terima kembali dari Google akan memungkinkan aplikasi 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 ditampilkan selama pertukaran code. Token refresh memberikan akses berkelanjutan ke API Google untuk aplikasi Anda saat pengguna tidak ada di aplikasi Anda. Untuk meminta token refresh, tambahkan dan tetapkan 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 batasan lainnya per pengguna di semua klien. Jika aplikasi Anda meminta terlalu banyak token refresh, aplikasi tersebut dapat mencapai batas ini, sehingga token refresh yang lebih lama berhenti berfungsi.

Untuk mengetahui informasi selengkapnya, lihat Memperbarui token akses (akses offline).

Anda dapat meminta pengguna untuk mengizinkan ulang aplikasi Anda dengan menyetel 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 telah diberikan sebelumnya 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.

Parameter Wajib Deskripsi
client_id (Wajib diisi) String client ID yang Anda dapatkan dari , seperti yang dijelaskan dalam Mendapatkan kredensial OAuth 2.0.
nonce (Wajib diisi) Nilai acak yang dihasilkan oleh aplikasi Anda yang memungkinkan perlindungan replay.
response_type (Wajib diisi) Jika nilainya adalah code, akan meluncurkan Alur kode otorisasi dasar, yang memerlukan POST ke endpoint token untuk mendapatkan token. Jika nilainya adalah token id_token atau id_token token, akan meluncurkan Alur implisit, yang memerlukan penggunaan JavaScript di URI pengalihan untuk mengambil token dari ID #fragment URI.
redirect_uri (Wajib diisi) Menentukan tujuan pengiriman respons. Nilai parameter ini harus sama persis dengan salah satu nilai pengalihan yang sah yang Anda tetapkan di (termasuk skema HTTP atau HTTPS, huruf besar/kecil, dan '/' di akhir, jika ada).
scope (Wajib diisi)

Parameter cakupan harus dimulai dengan nilai openid, lalu menyertakan nilai profile, nilai email, atau keduanya.

Jika nilai cakupan profile ada, token ID mungkin (tetapi tidak dijamin) menyertakan klaim profile default pengguna.

Jika nilai cakupan email ada, token ID akan menyertakan klaim email dan email_verified.

Selain cakupan khusus OpenID ini, argumen cakupan Anda juga dapat mencakup nilai cakupan lainnya. Semua nilai cakupan harus dipisahkan dengan spasi. Misalnya, jika Anda menginginkan akses per file ke Google Drive pengguna, parameter cakupan Anda mungkin openid profile email https://www.googleapis.com/auth/drive.file.

Untuk mengetahui informasi tentang cakupan yang tersedia, lihat Cakupan OAuth 2.0 untuk Google API atau dokumentasi untuk Google API yang ingin Anda gunakan.

state (Opsional, tetapi sangat direkomendasikan)

String buram yang dikirimkan bolak-balik dalam protokol; artinya, string tersebut ditampilkan sebagai parameter URI dalam alur Dasar, dan dalam #fragment ID URI dalam alur Implisit.

state dapat berguna untuk menghubungkan permintaan dan respons. Karena redirect_uri Anda dapat ditebak, penggunaan nilai state dapat meningkatkan kepastian Anda bahwa koneksi masuk adalah hasil dari permintaan autentikasi yang dimulai oleh aplikasi Anda. Jika Anda membuat string acak atau mengenkode hash beberapa status klien (misalnya, cookie) dalam variabel state ini, Anda dapat memvalidasi respons untuk memverifikasi bahwa permintaan dan respons berasal dari browser yang sama. Hal ini memberikan perlindungan terhadap serangan seperti pemalsuan permintaan lintas situs.

access_type (Opsional) Nilai yang diizinkan adalah offline dan online. Efeknya didokumentasikan dalam Akses Offline; jika token akses diminta, klien tidak akan menerima token refresh kecuali jika nilai offline ditentukan.
display (Opsional) Nilai string ASCII untuk menentukan cara server otorisasi menampilkan halaman antarmuka pengguna autentikasi dan izin. Nilai berikut ditentukan, dan diterima oleh server Google, tetapi tidak memengaruhi perilaku alur protokol: page, popup, touch, dan wap.
hd (Opsional)

Menyederhanakan proses login untuk akun yang dimiliki oleh organisasi Google Cloud. Dengan menyertakan domain organisasi Google Cloud (misalnya, mycollege.edu), Anda dapat menunjukkan bahwa UI pemilihan akun harus dioptimalkan untuk akun di domain tersebut. Untuk mengoptimalkan akun organisasi Google Cloud secara umum, bukan hanya satu domain organisasi Google Cloud, tetapkan nilai tanda bintang (*): hd=*.

Jangan mengandalkan pengoptimalan UI ini untuk mengontrol siapa yang dapat mengakses aplikasi Anda, karena permintaan sisi klien dapat dimodifikasi. Pastikan untuk memvalidasi bahwa token ID yang ditampilkan memiliki nilai klaim hd yang cocok dengan yang Anda harapkan (misalnya, mycolledge.edu). Tidak seperti parameter permintaan, klaim hd token ID terdapat dalam token keamanan dari Google, sehingga nilainya dapat dipercaya.

include_granted_scopes (Opsional) Jika parameter ini diberikan dengan nilai true, dan permintaan otorisasi diberikan, otorisasi akan mencakup otorisasi sebelumnya yang diberikan untuk kombinasi pengguna/aplikasi ini untuk cakupan lain; lihat Otorisasi inkremental.

Perhatikan bahwa Anda tidak dapat melakukan otorisasi inkremental dengan alur Aplikasi Terinstal.

login_hint (Opsional) Saat mengetahui pengguna mana yang sedang mencoba diautentikasi, aplikasi Anda dapat memberikan parameter ini sebagai petunjuk ke server autentikasi. Meneruskan petunjuk ini akan menyembunyikan pemilih akun dan mengisi otomatis kotak email pada formulir login, atau memilih sesi yang tepat (jika pengguna menggunakan login ganda), yang dapat membantu Anda menghindari masalah yang terjadi jika aplikasi Anda login ke akun pengguna yang salah. Nilainya dapat berupa alamat email atau string sub, yang setara dengan ID Google pengguna.
prompt (Opsional) Daftar nilai string yang dipisahkan dengan spasi yang menentukan apakah server otorisasi meminta pengguna untuk melakukan autentikasi ulang dan memberikan izin. Nilai yang mungkin adalah:
  • none

    Server otorisasi tidak menampilkan layar autentikasi atau izin pengguna; server akan menampilkan error jika pengguna belum diautentikasi dan belum mengonfigurasi izin untuk cakupan yang diminta. Anda dapat menggunakan none untuk memeriksa autentikasi dan/atau izin yang ada.

  • consent

    Server otorisasi meminta izin pengguna sebelum menampilkan informasi kepada klien.

  • select_account

    Server otorisasi meminta pengguna untuk memilih akun pengguna. Hal ini memungkinkan pengguna yang memiliki beberapa akun di server otorisasi untuk memilih di antara beberapa akun yang mungkin memiliki sesi saat ini.

Jika tidak ada nilai yang ditentukan dan pengguna belum pernah mengizinkan akses sebelumnya, maka pengguna akan melihat layar izin.

Memvalidasi token ID

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

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

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

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

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

Validasi token ID memerlukan beberapa langkah:

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

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

Langkah pertama lebih rumit, dan melibatkan pemeriksaan tanda tangan kriptografi. Untuk tujuan pen-debug-an, Anda dapat menggunakan endpoint tokeninfo Google untuk membandingkan dengan pemrosesan lokal yang diterapkan di server atau perangkat Anda. Misalkan nilai token ID Anda adalah XYZ123. Kemudian, Anda akan melakukan dereferensi URI https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123. Jika tanda tangan token valid, responsnya adalah 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 penemuan menggunakan nilai metadata jwks_uri. Permintaan ke endpoint pen-debugan mungkin di-throttle atau mengalami error sesekali.

Karena Google jarang mengubah kunci publiknya, Anda dapat meng-cache-nya menggunakan perintah cache respons HTTP dan, dalam sebagian besar kasus, melakukan validasi lokal dengan jauh lebih efisien daripada menggunakan endpoint tokeninfo. Validasi ini memerlukan pengambilan dan parsing sertifikat, serta melakukan panggilan kriptografi yang sesuai untuk memeriksa tanda tangan. Untungnya, ada library yang telah di-debug dengan baik dan tersedia dalam berbagai bahasa untuk melakukan hal ini (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 mematuhi 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 penemuan menggunakan nilai metadata userinfo_endpoint. Respons userinfo mencakup informasi tentang pengguna, seperti yang dijelaskan dalam OpenID Connect Standard Claims dan nilai metadata claims_supported dari dokumen Penemuan. Pengguna atau organisasi mereka dapat memilih untuk memberikan atau tidak memberikan informasi di kolom tertentu, sehingga Anda mungkin tidak mendapatkan informasi untuk setiap kolom dalam cakupan akses yang diizinkan.

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 penerapan 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, info pengguna, 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 meng-hardcode URI Dokumen penemuan (https://accounts.google.com/.well-known/openid-configuration) ke dalam aplikasi Anda. Aplikasi Anda mengambil dokumen, menerapkan aturan penyiapan cache dalam respons, lalu mengambil URI endpoint dari dokumen tersebut 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 yang ditentukan dalam OpenID Connect Discovery 1.0 (lihat dokumen tersebut untuk mengetahui artinya). Nilai tersebut murni ilustratif dan dapat berubah, meskipun disalin dari versi terbaru dokumen Google Discovery 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 pulang pergi HTTP dengan menyimpan nilai dari dokumen Penemuan dalam cache. Header caching HTTP standar digunakan dan harus dipatuhi.

Library klien

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

Kepatuhan OpenID Connect

Sistem autentikasi OAuth 2.0 Google mendukung fitur yang diperlukan dari spesifikasi OpenID Connect Core. Klien apa pun yang didesain untuk bekerja dengan OpenID Connect harus dapat beroperasi dengan layanan ini (kecuali Objek Permintaan OpenID).