OAuth 2.0 memiliki banyak alur kerja. Saya punya beberapa pertanyaan tentang keduanya.

1. Alur kode otorisasi - Pengguna masuk dari aplikasi klien, server otorisasi mengembalikan kode otorisasi ke aplikasi. Aplikasi kemudian menukar kode otorisasi dengan token akses.
2. Aliran hibah implisit - Pengguna masuk dari aplikasi klien, server otorisasi mengeluarkan token akses ke aplikasi klien secara langsung.

Apa perbedaan antara kedua pendekatan dalam hal keamanan? Mana yang lebih aman dan mengapa?

Saya tidak melihat alasan mengapa langkah tambahan (pertukaran kode otorisasi untuk token) ditambahkan dalam satu alur kerja ketika server dapat langsung mengeluarkan token Access.

Situs web yang berbeda mengatakan bahwa aliran kode Otorisasi digunakan ketika aplikasi klien dapat menjaga keamanan kredensial. Mengapa?

Ini access_tokenadalah apa yang Anda butuhkan untuk memanggil sumber daya yang dilindungi (API). Dalam aliran Kode Otorisasi ada 2 langkah untuk mendapatkannya:

1. Pengguna harus mengautentikasi dan mengembalikan a codeke konsumen API (disebut "Klien").
2. "Klien" API (biasanya server web Anda) menukar yang codediperoleh di # 1 dengan access_token, mengautentikasi sendiri dengan client_iddanclient_secret
3. Kemudian dapat memanggil API dengan access_token.

Jadi, ada pemeriksaan ganda: pengguna yang memiliki sumber daya muncul melalui API dan klien menggunakan API (misalnya aplikasi web). Keduanya divalidasi agar akses diberikan. Perhatikan sifat "otorisasi" OAuth di sini: pengguna memberikan akses ke sumber dayanya (melalui pengembalian codesetelah otentikasi) ke suatu aplikasi, aplikasi mendapatkan access_token, dan memanggil atas nama pengguna.

Dalam aliran implisit, langkah 2 dihilangkan. Jadi setelah otentikasi pengguna, sebuah access_tokendikembalikan secara langsung, yang dapat Anda gunakan untuk mengakses sumber daya. API tidak tahu siapa yang memanggil API itu. Siapa pun dengan access_tokenkaleng, sedangkan dalam contoh sebelumnya hanya aplikasi web akan (internal itu biasanya tidak dapat diakses oleh siapa pun).

Aliran implisit biasanya digunakan dalam skenario di mana penyimpanan client iddan client secrettidak dianjurkan (misalnya perangkat, meskipun banyak yang melakukannya). Itulah yang dimaksud penafian. Orang-orang memiliki akses ke kode klien dan karenanya dapat memperoleh kredensial dan berpura-pura menjadi klien sumber daya. Dalam aliran implisit semua data volatile dan tidak ada yang disimpan di aplikasi.

Saya akan menambahkan sesuatu di sini yang saya pikir tidak dijelaskan dalam jawaban di atas:

• Otorisasi-Kode-Alur memungkinkan token akses akhir untuk tidak pernah mencapai dan tidak pernah disimpan pada mesin dengan browser / aplikasi . Kode otorisasi sementara diberikan kepada mesin dengan browser / aplikasi, yang kemudian dikirim ke server. Server kemudian dapat menukar dengan token akses penuh dan memiliki akses ke API dll. Pengguna dengan browser mendapatkan akses ke API hanya melalui server dengan token.
• Aliran tersirat hanya dapat melibatkan dua pihak, dan token akses akhir disimpan pada klien dengan browser / aplikasi. Jika peramban / aplikasi ini dikompromikan, maka token autentik mereka yang mungkin berbahaya.

tl; dr tidak menggunakan aliran implisit jika Anda tidak percaya mesin pengguna untuk token terus tetapi Anda lakukan percaya server Anda sendiri.

Perbedaan antara keduanya adalah:

1. Dalam aliran tersirat, token dikembalikan langsung melalui URL pengalihan dengan tanda "#" dan ini digunakan terutama pada klien javascript atau aplikasi seluler yang tidak memiliki sisi server sendiri, dan klien tidak perlu memberikan rahasianya dalam beberapa implementasi .

2. Dalam aliran kode Otorisasi, kode dikembalikan dengan "?" agar dapat dibaca oleh sisi server maka sisi server harus memberikan rahasia klien kali ini ke token url untuk mendapatkan token sebagai objek json dari server otorisasi. Ini digunakan jika Anda memiliki server aplikasi yang dapat menangani hal ini dan menyimpan token pengguna dengan profilnya di sistemnya sendiri, dan sebagian besar digunakan untuk aplikasi seluler umum.

jadi itu tergantung pada sifat aplikasi klien Anda, mana yang lebih aman "kode otorisasi" karena meminta rahasia pada klien dan token dapat dikirim antara server otorisasi dan aplikasi klien pada koneksi yang sangat aman, dan penyedia otorisasi dapat batasi beberapa klien untuk hanya menggunakan "Kode Otorisasi" dan melarang Implisit

Hibah implisit mirip dengan hibah kode otorisasi dengan dua perbedaan yang berbeda.

Ini dimaksudkan untuk digunakan untuk klien berbasis agen pengguna (misalnya aplikasi web satu halaman) yang tidak dapat menjaga rahasia klien karena semua kode aplikasi dan penyimpanan mudah diakses.

Kedua alih-alih server otorisasi mengembalikan kode otorisasi yang ditukar dengan token akses, server otorisasi mengembalikan token akses.

Silakan temukan detailnya di sini http://oauth2.thephpleague.com/authorization-server/which-grant/

Aliran tersirat

Keuntungan

• Sederhana untuk diterapkan

Kekurangan

• Akses token yang terlihat oleh browser
• Asal token akses tidak dapat ditentukan
• Token akses tidak boleh kedaluwarsa (berdasarkan kebijakan Google)

Alur kode otorisasi

Keuntungan

• Paling aman
• Token akses dan token penyegaran hanya dapat dibuat jika rahasia bersama diketahui
• Dapat ditingkatkan dengan fitur keamanan dan UX baru ketika tersedia

Kekurangan

• Harus menerapkan beberapa titik akhir auth

Kutipan: https://developers.google.com/actions/develop/identity/oauth2-overview#supported_oauth_20_flows

Biarkan saya merangkum poin-poin yang saya pelajari dari jawaban di atas dan tambahkan beberapa pemahaman saya sendiri.

Alur Kode Otorisasi !!!

• Jika Anda memiliki server aplikasi web yang bertindak sebagai klien OAuth
• Jika Anda ingin memiliki akses berumur panjang
• Jika Anda ingin memiliki akses offline ke data
• ketika Anda bertanggung jawab untuk panggilan api yang dibuat oleh aplikasi Anda
• Jika Anda tidak ingin membocorkan token OAuth Anda
• Jika Anda tidak ingin aplikasi dijalankan melalui aliran otorisasi setiap kali diperlukan akses ke data. CATATAN: Aliran Hibah Implisit tidak menghibur token penyegaran jadi jika server otorisasi kedaluwarsa mengakses token secara teratur, aplikasi Anda akan perlu dijalankan melalui aliran otorisasi kapan pun ia membutuhkan akses.

Aliran Hibah Tersirat !!!

• Ketika Anda tidak memiliki Server Aplikasi Web untuk bertindak sebagai Klien OAuth
• Jika Anda tidak membutuhkan akses yang tahan lama, hanya diperlukan akses sementara ke data.
• Jika Anda mempercayai browser tempat aplikasi Anda berjalan dan ada kekhawatiran terbatas bahwa token akses akan bocor ke pengguna yang tidak dipercaya.

Mana yang lebih aman dan mengapa?

Keduanya aman, tergantung pada lingkungan yang Anda gunakan.

Saya tidak melihat alasan mengapa langkah tambahan (pertukaran kode otorisasi untuk token) ditambahkan dalam satu alur kerja ketika server dapat langsung mengeluarkan token Access.

Sederhana saja. Klien Anda tidak aman. Mari kita lihat secara detail.

Pertimbangkan Anda membuat aplikasi yang menentang Instagram API, sehingga Anda mendaftarkan aplikasi Anda dengan Instagramdan menentukan yang API'sAnda butuhkan. Instagramakan memberi Anda client_iddanclient_secrect

Di situs web Anda, Anda membuat tautan yang mengatakan. "Datang dan Gunakan Aplikasi Saya". Mengklik ini aplikasi web Anda harus membuat dua panggilan Instagram API.

Firstkirim permintaan ke Instagram Authentication Serverdengan parameter di bawah ini.

1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token. 

Anda tidak mengirimclient_secret , Anda tidak bisa mempercayai klien (Pengguna dan peramban yang mencoba menggunakan aplikasi Anda). Klien dapat melihat url atau skrip java dan menemukan Anda client_secrectdengan mudah. Inilah sebabnya mengapa Anda perlu langkah lain.

Anda menerima codedan state. Di codesinitemporary dan tidak disimpan di mana pun.

Kemudian Anda melakukan secondpanggilan ke Instagram API(dari server Anda)

 1. `grant_type` with the value of `authorization_code`
 2. `client_id` with the client identifier
 3. `client_secret` with the client secret
 4. `redirect_uri` with the same redirect URI the user was redirect back to
 5. `code` which we have already received.

Karena panggilan dilakukan dari server kami, kami dapat menggunakan dengan aman client_secret(yang menunjukkan bagaimana kami) dengan codeyang menunjukkan pengguna telah memberikanclient_id untuk menggunakan sumber daya.

Sebagai tanggapan kita akan memiliki access_token

Dari perspektif praktis (Apa yang saya mengerti), Alasan utama untuk memiliki aliran kode Authz adalah:

1. Dukungan untuk token penyegaran (akses jangka panjang oleh aplikasi atas nama Pengguna), tidak didukung secara implisit: rujuk: https://tools.ietf.org/html/rfc6749#section-4.2
2. Dukungan untuk halaman persetujuan yang merupakan tempat di mana Pemilik Sumber Daya dapat mengontrol akses apa yang disediakan (Jenis izin / halaman otorisasi yang Anda lihat di google). Sama tidak ada secara implisit. Lihat bagian: https://tools.ietf.org/html/rfc6749#section-4.1 , point (B)

"Server otorisasi mengotentikasi pemilik sumber daya (melalui agen-pengguna) dan menetapkan apakah pemilik sumber daya mengabulkan atau menolak permintaan akses klien"

Selain itu, Menggunakan token penyegaran, Aplikasi bisa mendapatkan akses jangka panjang ke data pengguna.

Tampaknya ada dua poin kunci, tidak dibahas sejauh ini, yang menjelaskan mengapa jalan memutar dalam Jenis Hibah Kode Otorisasi menambah keamanan.

Cerita pendek : Jenis Hibah Kode Otorisasi menyimpan informasi sensitif dari riwayat peramban, dan transmisi token hanya bergantung pada perlindungan HTTPS dari server otorisasi.

Versi yang lebih panjang:

Berikut ini, saya akan tetap menggunakan terminologi OAuth 2 yang didefinisikan dalam RFC (ini adalah bacaan cepat): server sumber daya , klien , server otorisasi , pemilik sumber daya .

Bayangkan Anda ingin beberapa aplikasi pihak ketiga (= klien) mengakses data tertentu dari akun Google Anda (= server sumber daya). Anggap saja Google menggunakan OAuth 2. Anda adalah pemilik sumber daya untuk akun Google, tetapi saat ini Anda mengoperasikan aplikasi pihak ketiga.

Pertama, klien membuka browser untuk mengirim Anda ke URL aman server otorisasi Google. Kemudian Anda menyetujui permintaan untuk akses, dan server otorisasi mengirim Anda kembali ke URL pengalihan yang sebelumnya diberikan klien, dengan kode otorisasi dalam string kueri. Sekarang untuk dua poin utama:

1. URL pengalihan ini berakhir di riwayat browser . Jadi kami tidak ingin token yang berumur panjang, langsung dapat digunakan di sini. Kode otorisasi berumur pendek kurang berbahaya dalam sejarah. Perhatikan bahwa jenis Hibah Implisit memang memasukkan token dalam sejarah.
2. Keamanan pengalihan ini tergantung pada sertifikat HTTPS klien , bukan pada sertifikat Google. Jadi kami mendapatkan keamanan transmisi klien sebagai vektor serangan tambahan (Agar hal ini tidak dapat dihindari, klien harus non-JavaScript. Karena jika tidak, kami dapat mengirimkan kode otorisasi melalui URL fragmen, di mana kode tidak akan melalui jaringan. Ini mungkin menjadi alasan mengapa Jenis Hibah Tersirat, yang memang menggunakan URL fragmen, dulu direkomendasikan untuk klien JavaScript, meskipun itu tidak lagi.)

Dengan Jenis Hibah Kode Otorisasi, token akhirnya diperoleh dengan panggilan dari klien ke server otorisasi, di mana keamanan transmisi hanya tergantung pada server otorisasi , bukan pada klien.