Membiarkan atau tidak membiarkan? Itu pertanyaannya ...Sekarang di banyak situs kami melihat peluang untuk mendaftar atau masuk menggunakan jejaring sosial, dan beberapa situs menawarkan penggunaan kunci keamanan eksternal atau sidik jari. Apa itu? Standar keamanan yang dirancang dengan baik atau implementasi hak milik? Bisakah kita mempercayai teknologi ini dan menggunakannya untuk pengembangan situs web dan dalam kehidupan sehari-hari? Mari kita perbaiki. Jadi, sekarang ada beberapa standar dan teknologi untuk mengidentifikasi pengguna OAuth 2.0, OpenID Connect, WebAuthn, SAML 2.0, Credential Management API, dll. Pada artikel ini saya akan berbicara tentang tiga protokol yang paling menjanjikan OAuth 2.0, OpenID Connect dan WebAuthn. Dan untuk memahami cara mempraktikkannya, kami akan melakukan tiga pekerjaan laboratorium. Kami akan menggunakan GitHub dan Google sebagai platform untuk mengidentifikasi pengguna.di mana sebagian besar memiliki akun.
OAuth 2.0
Mari kita mulai dengan protokol OAuth 2.0 yang paling terkenal. Itu diterbitkan pada 2012 sebagai RFC 6749: Kerangka Otorisasi OAuth 2.0 .Menggunakan OAuth 2.0, pengguna mengizinkan situs tertentu untuk menerima data pribadi mereka dari jejaring sosial, tetapi tanpa mentransfer login / kata sandi mereka ke situs. Misalnya, ketika Anda mendaftar di situs melalui Facebook, maka Anda cukup memberikan izin situs ini untuk mendapatkan nama, alamat email, dan data pribadi lainnya dari Facebook.Mari kita berurusan dengan implementasi teknis. Untuk mempermudah, saya akan menelepon situs apa pun yang menyimpan kredensial pengguna di Jejaring Sosial. Dan MySite akan memberi nama situs atau aplikasi apa pun yang ingin mendapatkan data pengguna dari Jejaring Sosial.
Standar mendefinisikan peran berikut:- Resource Owner — , MySite .
- Client ( MySite) — , Authorization Server Resource Server .
- Authorization Server — / , .
- Resource Server — , API. Authorization Server Resource Server .
Authorization flow
- MySite :
- MySite Name ( ), Homepage ( MySite) Callback (, )
- Jejaring sosial memberikan ID Klien (kadang-kadang disebut AppID) dan Rahasia Klien.
- ID pengembang harus terdaftar dalam ID Klien dan Rahasia Klien.
Sekarang prosesnya sendiri. Rincian implementasi spesifik dapat bervariasi, tetapi logika umum akan selalu sebagai berikut:
- Pemilik Sumber Daya masuk ke Klien (MySite), memilih opsi "masuk menggunakan Jaringan Sosial", situs mengarahkan pengguna ke Jaringan Sosial pada Server Otorisasi.
- Server Otorisasi memeriksa apakah pengguna memiliki sesi aktif dan, jika tidak, kemudian menampilkan formulir login.
- Resource Owner memasukkan nama pengguna / kata sandi dan mengonfirmasi bahwa data pribadi tertentu dapat digunakan oleh MySite, seperti nama pengguna atau alamat email.
- Server Otorisasi memverifikasi pengguna dan mengalihkan ke alamat Callback dengan hasil otentikasi dan "Kode Otorisasi"
- Client “Authorization Code”, Client ID Client Secret.
- Authorization Server “access token” JWT (JSON Web Token), . JWT “refresh token”, c .
- Client API, “access token”.
- Resource Server “access token” (, Authorization Server) .
OAuth 2.0 (GitHub)
Ada banyak instruksi tentang bagaimana menerapkan otorisasi OAuth 2.0 menggunakan jejaring sosial. Saya pribadi menyukai artikel berikut: Otentikasi menggunakan GitHub OAuth 2.0 dengan NodeJS Ini merinci langkah-langkahnya dan menyediakan program pengujian. Tetapi untuk benar-benar memahami algoritme, lebih baik melalui semua langkah dengan tangan Anda (permintaan http dari browser atau panggilan ke ikal). Pergilah.Untuk memulai, daftarkan aplikasi Anda di GitHub: github.com/settings/applications/newSetel parameter:Agar otorisasi untuk bekerja di dalam situsnya sendiri, alamat harus asli, tetapi ini tidak perlu untuk pekerjaan laboratorium.Dapatkan dari GitHub:- ID Klien: ab8ec08a620c2
- Rahasia Klien: e6fdd52b0a99e8fbe76b05c1b7bb93c1e
Tentu saja, di semua pekerjaan laboratorium semua nilai itu palsu.Ini adalah bagaimana mendapatkan ID Klien dan Rahasia di situs web GitHub terlihat seperti:
Sekarang kita mulai otorisasi. Kami percaya bahwa Langkah 1 telah selesai: pengguna masuk ke MySite dan memilih "Masuk menggunakan GitHub". Langkah 2 dari aliran panggilan adalah panggilan dalam format REST:https://github.com/login/oauth/authorize?client_id=ab8ec08a620c2
- alamatnya adalah titik masuk di github
- client_id adalah ID Klien yang dikeluarkan saat pendaftaran
Sebagai hasil dari panggilan ini, GitHub menampilkan jendela untuk otorisasi:
Langkah 3: Masukkan login / kata sandi untuk mengakses GitHubLangkah 4: GitHub mengalihkan permintaan ke Beranda, dalam permintaan ini kita melihat kode:http://MySite/home?code=a29b348f63d21
Tidak ada situs yang berfungsi di alamat ini, tetapi hal utama bagi kami adalah mengetahui kode yang dikirim untuk membentuk Langkah 5 berikutnya:https://github.com/login/oauth/access_token?client_id=ab8ec08a620c2&
client_secret=e6fdd52b0a99e8fbe76b05c1b7bb93c1e&
code=a29b348f63d21
- alamatnya adalah titik penerimaan token akses di GitHub
- client_id adalah ID Klien yang dikeluarkan saat pendaftaran
- client_secret adalah Rahasia Klien yang dikeluarkan selama pendaftaran
- kode adalah kode yang baru saja dikirim
Langkah 6: Sebagai tanggapan, token akses yang diterima:access_token=31b71cbd372acdbb20ec1644b824f3dd0&scope=&token_type=bearer
Langkah 7: Masukkan access_token ke header permintaan dan panggil API GitHub:curl -H "Authorization: token 31b71cbd372acdbb20ec1644b824f3dd0" https://api.github.com/user
Langkah 8: Sebagai tanggapan, kami mendapatkan JSON dengan informasi berguna tentang saya yang dapat Anda gunakan untuk membuat profil di MySite:{
"login": "AlexeySushkov",
"html_url": "https://github.com/AlexeySushkov",
"repos_url": "https://api.github.com/users/AlexeySushkov/repos",
"name": "Alexey Sushkov",
"blog": "http://sushkov.ru",
"location": "St.Petersburg, Russia",
"email": "alexey.p.sushkov@gmail.com",
..
}
Faktanya, kami hanya memeriksa satu skenario OAuth 2.0. Ada beberapa skenario, yang masing-masing digunakan tergantung pada aplikasi, pertimbangan keamanan, metode penyebaran, dll. Deskripsi semua skenario dapat ditemukan, misalnya, di sini: OAuth 2.0 in a Nutshell .Openid connect
Dengan OAuth 2.0 sedikit dipahami. Sekarang mari kita cari tahu mengapa kita membutuhkan OpenID Connect, yang merupakan tambahan untuk OAuth 2.0:- C OAuth 2.0 .. access token, . access token MySite. OpenID Connect — (identity). .
- OpenID Connect “service discovery”. SSO (Single Sign-On), .
Mari kita lihat standar dari sisi teknis.OpenID Connect (OIDC) adalah standar OpenID terbuka yang dikembangkan oleh konsorsium OpenID Foundation . OIDC memperluas OAuth 2.0 dengan fitur-fitur utama berikut:- Server Otorisasi, selain mengakses token dan menyegarkan token, mengembalikan "token identitas" (ID Token). Itu terkandung dalam JWT yang sama. Informasi berikut dapat diekstrak dari ID Token: nama pengguna, waktu masuk, tanggal kedaluwarsa ID Token. ID Token dapat ditransfer antar peserta.
- OIDC menyediakan API tambahan yang memungkinkan Anda untuk meminta informasi tentang pengguna dan sesi saat ini.
Diagram interaksi di OpenID Connect terlihat sama dengan OAuth. Satu-satunya perbedaan dalam isi permintaan:- Dalam permintaan awal untuk kode, atribut tambahan, scope = openid, ditambahkan.
- Sebagai hasil dari algoritma, Klien, selain mengakses dan menyegarkan token, menerima ID Token.
OpenID Connect: Lab (Google)
Sekarang mari kita lihat apa yang Google akan menyenangkan kita tentang topik ini. Ada instruksi terperinci untuk mengonfigurasi dan menggunakan OpenID Connect dari Google dan kotak pasir untuk menggunakan Google API: Google OAuth 2.0 Playground .Di sini, seperti dalam kasus OAuth 2.0, kita akan melalui langkah-langkah dan melihat data yang masuk. Demikian pula, kami percaya bahwa aplikasi terdaftar, ID Klien dan Rahasia Klien diterima, Langkah 1 terlewati. Langkah 2 dari aliran panggilan adalah panggilan dalam format REST:https://accounts.google.com/o/oauth2/v2/auth?
response_type=code&
client_id=140797064495-b8b79j42m97nkkrlndfstikv8.apps.googleusercontent.com&
scope=openid%20email&
redirect_uri=http%3A//c18529.shared.hc.ru/wp-login.php&
state=765439764
Google sedikit lebih rumit, karena mereka lebih memperhatikan keamanan:- alamat adalah titik masuk di Google
- response_type = kode - berharap menerima kode sebagai respons
- client_id - ID Klien dikeluarkan saat pendaftaran
- scope = email openid - data apa yang ingin kita akses
- redirect_uri - redirect_uri ditentukan saat pendaftaran aplikasi
- negara - nomor yang dihasilkan oleh Klien, yang ditransmisikan antara Klien dan AS untuk melindungi terhadap gangguan penyusup.
Langkah 3: Tidak ada formulir entri kata sandi, seperti Saya sudah masuk ke Google.Langkah 4: Google mengalihkan permintaan ke Beranda, dalam permintaan ini kita melihat kode:http://MySite?state=123&code=4/xAFkcMzhyJhUErRJYwIyntSYN-WeJjfZHLiwWL4IaT-WkHzMU18xABlPmev-M_87wVbqTkQ1y93w6GB5&scope=email+openid+https://www.googleapis.com/auth/userinfo.email&authuser=0&prompt=none
Seperti dalam kasus GitHub, tidak ada situs web yang berfungsi di alamat ini, tetapi ini tidak perlu, hal utama bagi kami adalah mengetahui kode untuk membentuk Langkah selanjutnya 5. Ini juga sedikit lebih rumit, karena Google membutuhkan permintaan POST, bukan GET:curl -d "code=4/xAFkcMzhyJhUErRJYwIyntSYN-WeJjfZHLiwWL4IaT-WkHzMU18xABlPmev-M_87wVbqTkQ1y93w6GB5&client_id=140797064495-b8b79j42m97nkkrlndfstikv8.apps.googleusercontent.com&
client_secret=HMVctrTicW6RC1Q8T&
redirect_uri=http%3A//c18529.shared.hc.ru/wp-login.php&
grant_type=authorization_code"
-H "Content-Type: application/x-www-form-urlencoded" -X POST https://oauth2.googleapis.com/token
- alamat adalah titik penerimaan token di Google
- kode adalah kode yang baru saja dikirim
- client_id adalah ID Klien yang dikeluarkan saat pendaftaran
- client_secret adalah Rahasia Klien yang dikeluarkan selama pendaftaran
- grant_type = authorization_code - satu-satunya nilai yang valid dari standar
Langkah 6: Sebagai tanggapan menerima access_token dan id_token:{
"access_token": "ya29.Il_AB0KeKnjBJx0dhjm2nCLt1B-Mq0aQBW5T302JnlZfsxW1AXqLFfDJZRMi2R2WKG4OX4msKLjx4E4CSl4G_4ajAy3aqrf4pM0ic0jJr092pA67H9aktJktCbx",
"expires_in": 3327,
"scope": "openid https://www.googleapis.com/auth/userinfo.email",
"token_type": "Bearer",
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjE3ZDU1ZmY0ZTEwOTkxZDZiMGVmZDM5MmI5MWEzM2U1
………………………………_…………………………………………………….._4mUTiMNSAHljap1hLD2hAzgOZWuQ"
}
Apa yang harus dilakukan sekarang dengan kekayaan ini?Langkah 7: Dengan access_token semuanya jelas: kami memasukkannya dalam panggilan API, misalnya GMail:curl -H "Authorization: Bearer ya29.a0Adw1xeWvFoxHKNICHnV6vFFj5TZdPQVlYD98h8wjW95ZEbHVui_pk7HGRoq3Q7MlVLV23xkVM0yyjSP8ClSlvfUy3b_IqvKQW5Lvwj38QzJhee-aH1grerB4pRpMzn_FGueigG_RGI56pKPgFBTr49cpynQy" https://www.googleapis.com/gmail/v1/users/alexey.p.sushkov@gmail.com/profile
Langkah 8: Sebagai tanggapan, kami mendapatkan JSON dengan informasi yang berguna:{
"emailAddress": "alexey.p.sushkov@gmail.com",
"messagesTotal": 372543,
...
}
Sekarang mari kita periksa pernyataan bahwa id_token berisi informasi untuk mengotentikasi pengguna dan mempertahankan sesi. Untuk melakukan ini, Anda perlu mendekripsi isinya. Cara termudah untuk melakukan ini adalah dengan menghubungi Google API dioauth2.googleapis.com/tokeninfo dan tentukan id_token yang diterima sebagai parameter:https://oauth2.googleapis.com/tokeninfo?id_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjE3ZDU1ZmY0ZTEwOTkxZDZiMGVmZDM5MmI5MWEzM2U1NGMwZTIxOGIiLCJ0eXAiOi
………………………_……………………………...
SVQ5GQni3irfOzOXYEiqijp6TjGa_a-3jKcEsU5TbasZmAIejsdVcNy2_4mUTiMNSAHljap1hLD2hAzgOZWuQ
Punya JSON:{
"iss": "https://accounts.google.com",
"email": "alexey.p.sushkov@gmail.com",
"email_verified": "true",
"iat": "1583257010",
"exp": "1583260610",
"typ": "JWT"
...
}
Kami melihat bahwa id_token berisi informasi tentang login pengguna, waktu penerimaan dan masa pakai token. Kami dapat menyimpulkan bahwa OpenID Connect dari Google berfungsi, dan itu dapat digunakan untuk skenario yang relevan.Webauthn
API Otentikasi Web (juga dikenal sebagai WebAuthn):- Standar ini memungkinkan pengguna untuk mengidentifikasi diri mereka di situs dan dalam aplikasi menggunakan kunci keamanan eksternal (misalnya, kunci USB) atau dengan sidik jari dan, selanjutnya, oleh data biometrik lainnya: wajah, retina.
- — / «Public key cryptography». Public key cryptography — , . Private key ( ) , public key ( ) .
- W3C (World Wide Web Consortium) FIDO, Google, Mozilla, Microsoft, Yubico. W3C HTTP, HTML, XML . WebAuthn. WebAuthn : Chrome, Firefox, Edge, Safari.
Dibandingkan dengan OAuth 2.0, WebAuthn menambahkan peran berikut:Authenticator : kunci keamanan eksternal (medium fisik atau pemindai sidik jari) yang memungkinkan Anda untuk mengautentikasi pengguna menggunakan berbagai teknologi, seperti BlueTooth / NFC / USB. Melayani untuk:- Generasi kredensial kunci publik (pasangan kunci publik / pribadi).
- Authenticator dengan aman menyimpan kunci pribadi dalam memorinya
- Melewati kunci publik ke sistem eksternal
- Menandatangani data dengan kunci pribadi dan mentransfer hasilnya ke sistem eksternal
Authenticator menggunakan protokol CTAP (Client to Authenticator Protocols) untuk berinteraksi dengan browser.Mengandalkan Pihak : melakukan fungsi yang sama dengan "Server Otorisasi" di OAuth 2.0, yaitu, memverifikasi identitas pengguna. Hanya di OAuth 2.0 itu adalah nama pengguna / kata sandi, dan dalam WenAuthn itu adalah kredensial kunci publik.Agen Pengguna : mengintegrasikan browser dan aplikasi jaringan, melayani tujuan yang sama dengan Klien dalam OAuth 2.0, yaitu, di satu sisi, berinteraksi dengan pengguna dan memberinya GUI, dan di sisi lain, berinteraksi dengan sistem yang menyimpan kredensial pengguna .Alur otorisasi
Sebelum memulai proses otentikasi, seperti di OAuth 2.0, Anda perlu melakukan langkah persiapan, hanya di OAuth 2.0 kami mendaftarkan aplikasi, dan di WebAuth 2.0 kami mendaftarkan pengguna. API Otentikasi Web menetapkan dua panggilan:- navigator.credentials.create - untuk membuat kredensial pengguna
- navigator.credentials.get - memverifikasi kredensial pengguna
Karenanya, untuk mendaftar, Anda harus menghubungi navigator.credentials.create.Sebagai akibatnya, Authenticator pengguna akan menyimpan kunci pribadi untuk situs tertentu, dan kunci publik akan disimpan di Pihak yang Mengandalkan.
Setelah itu, proses otentikasi adalah sebagai berikut:
- “WebAuthn”. , , WebAuthn, “ ” “ ”. Relying Party Challenge. Challenge — , Code OAuth 2.0.
- Relying Party Challenge. , REST API.
- Authenticator- CTAP (Client to Authenticator Protocols). navigator.credentials.get c :
- Authenticator , , .
- , Authenticator .
- Aplikasi mengirimkan data yang ditandatangani ke Pihak yang Mengandalkan.
- Mengandalkan Pihak mendekripsi data menggunakan kunci publik, memeriksa Tantangan dan mengotorisasi pengguna.
Untuk memperbaiki bahan kami melakukan pekerjaan laboratorium:WebAuthn: Lab (Google)
Untuk mengimplementasikan WebAuthn, hanya permintaan http yang tidak dapat diabaikan, sebagai Anda perlu memanggil API browser untuk berinteraksi dengan Authenticator. Tapi di sini Google senang, membuat kotak pasir dengan instruksi langkah-demi-langkah: WebAuthn pertama Anda .Sebagai hasil dari pekerjaan ini, kami mendapatkan aplikasi server klien JS yang mengimplementasikan otentikasi sidik jari. Demi yang berfungsi terletak di .Jika Anda menjalankannya di smartphone dengan sensor sidik jari, Anda dapat melihat hasil kerjanya. Seperti biasa, persiapan pertama - daftarkan pengguna:
Buat nama pengguna / kata sandi dan kemudian lampirkan sidik jari:
Setelah itu, program menunjukkan kunci publik mana yang dilampirkan pada sidik jari ini:
Sekarang Anda dapat memulai skrip otentikasi. Seperti biasa, kami percaya bahwa Langkah 1 telah selesai dan kami ada di situs. Untuk pergi ke Langkah 2, klik "Coba Reauth". Browser akan melakukan Langkah 3 dan akan berinteraksi dengan Authenticator, yang pada Langkah 4 akan meminta Anda untuk melampirkan jari Anda:
Dan jika jari yang terdaftar terpasang, maka Langkah 5 dan 6 akan lulus dengan sukses dan pada Langkah 7 aplikasi akan kembali menampilkan jendela dengan kunci publik yang sesuai:
Kesimpulan
Jadi, kami memeriksa tiga protokol yang paling umum dan menjanjikan untuk identifikasi pengguna: OAuth 2.0, OpenID Connect, WebAuthn. Kami memahami ruang lingkup penerapannya:- OAuth 2.0 - digunakan untuk mendaftar dan login pengguna ke situs menggunakan jejaring sosial. Dan juga untuk mendapatkan data pengguna dari jejaring sosial.
- OpenID Connect — . OpenID Connect SSO .
- WebAuthn — .
- , , .
- , , .
- Masuk akal untuk mengautentikasi pengguna ke platform cloud seperti Facebook atau Google, sebagai mereka mempekerjakan para pakar keamanan terbaik yang dapat memberikan semua nuansa keamanan.
- Saya sarankan optimis tentang masa depan, karena Protokol WebAuthn - kesempatan nyata untuk menyingkirkan kata sandi yang sulit di zaman kita!
Itu baru permulaan!Lampiran: protokol otentikasi lainnya
Untuk kelengkapan, saya akan mencantumkan protokol dan teknologi terkait lainnya yang digunakan untuk mengidentifikasi pengguna:SAML 2.0 (Bahasa Markah Pernyataan Keamanan)
Protokol yang matang tahun 2005, tetapi memiliki serangkaian skenario terbatas untuk membangun sistem SSO. Menggunakan format data berbasis XML. Rincian lebih lanjut dapat ditemukan di artikel: "Siapa yang menggunakan protokol otentikasi SAML 2.0"API Manajemen Kredensial
Pengembangan dilakukan oleh organisasi yang sama dengan WebAuthn - W3C. Standar Manajemen Kredensial memungkinkan Anda untuk:- Menyimpan identitas pelanggan, yang memungkinkan pengguna untuk mengakses situs tanpa memasukkan kata sandi, tetapi menggunakan kata sandi dari toko.
- Pilih akun yang diperlukan untuk memasuki situs tertentu.
- Memungkinkan Anda menggunakan login / kata sandi yang dimasukkan pada satu perangkat di perangkat lain.
Contoh implementasi umum dari Credential Management API adalah pengelola kata sandi Google: passwords.google.comInisiatif untuk Otentikasi Terbuka (OATH)
Sumber daya sumpahDaftar Lengkap Protokol Berbasis OAuth 2.0