Apa perbedaan antara Kode Otorisasi OAuth dan alur kerja implisit? Kapan harus menggunakan masing-masing?


165

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?


Jawaban:


204

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.


Terima kasih atas penjelasan Anda, tetapi saya tidak mengerti mengapa kami membutuhkan aliran Kode Otorisasi lain. Kami dapat mencapai hasil yang sama di server dengan aliran implisit (access_token) dan token penyegaran. Kelihatannya satu-satunya pertimbangan keamanan aliran implisit adalah bahwa access_code harus berumur pendek sehingga tidak dapat digunakan di server ke server. Oke, tetapi token penyegaran menyelesaikan masalah ini. Mengapa kita harus menggunakan aliran auth_code dan meminta access_token dengan itu di server untuk mendapatkan access_code?
Mohammad Nikravan

Yah ... begitulah cara protokol bekerja. Anda mungkin ingin membaca analisis ancaman spesifik untuk referensi yang lebih terperinci tentang manfaat keamanan satu dan lainnya.
Eugenio Pace

Saya tahu jawaban asli lebih dari 5 tahun, tetapi ini adalah penjelasan paling sederhana dan paling bersih yang pernah saya baca. Terima kasih @EugenioPace
Taha Ahmad

1
@ Madnik7G Alasannya adalah ortogonal untuk apa jawaban ini menjelaskan (indah): mungkin ada pihak ketiga yang terlibat. Seluruh aliran diatur oleh agen-pengguna (misalnya: browser), tetapi pada akhirnya server otorisasi (misalnya: "Login dengan Facebook") akan berbicara langsung dengan klien (katakanlah, BFF sisi server Anda) yang akan akhirnya mengakses sumber daya, sehingga agen-pengguna tidak pernah memiliki akses langsung.
Daniel Langdon

Terima kasih! Ya, ada 3 komunikasi yang terjadi: browser dan AS 9e.g. Facebook). Itu adalah /authorizepermintaannya. Browser dan situs web mencoba memanggil API (alias klien). Itu adalah redirect_uri+ yang codedikembalikan oleh AS setelah otentikasi berhasil. Akhirnya, klien memanggil AS di belakang layar, bertukar codeuntuk access_token. Ini adalah token endpointdalam literatur. Secara umum SA tidak pernah memanggil siapa pun. Itu selalu balasan.
Eugenio Pace

52

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.


12
re: Pengguna dengan browser mendapat akses ke API hanya melalui server dengan token. Tetapi server perlu mengirim sesuatu ke browser sehingga permintaan masuk dapat dikaitkan dengan token yang diadakan di sisi server. Cookie jika Anda suka. Jika server tidak mengirimkan token ke JS yang berjalan di browser, ia harus mengirimkan sesuatu yang lain, yang (browser) klien harus lewati ke server, agar server dapat bertindak atas nama klien tertentu.
Cheeso

Ya, sebuah cookie. Dengan demikian, Anda harus mengatur server dan klien browser Anda agar terlindung dari pemalsuan permintaan lintas situs.
Marcel

@ Marscel Saya ingin tahu bahwa setelah kami mendapatkan kode, bagaimana dan di mana pertukaran terjadi untuk mendapatkan yang sebenarnya access_tokendengan bantuan authorization code.
chirag soni

14

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


Kode otorisasi disimpan di sisi server selama 10 menit untuk facebook. Ini dirilis pada perubahan Desember 5.2012 mereka. Pertanyaan saya terutama adalah, apa perbedaan antara 2 dalam hal keamanan / kinerja. Saya tahu apa yang dilakukan kedua arus - tetapi apa keuntungan menggunakan kode otorisasi - menambahkan satu langkah lagi ke alur kerja.
divyanshm

itu tidak mengirim token ke aplikasi pengguna langsung koneksi antara aplikasi klien dan server otorisasi disembunyikan dari pengguna, dan seperti yang saya sebutkan itu bisa menjadi saluran yang sangat aman tidak sama dengan yang dari pengguna ke aplikasi klien.
Bassem Reda Zohdy

kinerja dalam kode Otorisasi Anda menekan server auth dua kali sehingga membutuhkan lebih banyak waktu, juga server klien akan menyimpan token pengguna dan ini akan menambah lebih banyak waktu juga.
Bassem Reda Zohdy

2
Oh baiklah! Saya mungkin telah mengabaikan ini. Jadi pada dasarnya, aliran kode otorisasi akan digunakan oleh sistem di mana seluruh server adalah klien - browser membuat permintaan dan mendapatkan kode. kode dikirim ke server klien yang terhubung ke server sumber daya dengan aman. Apakah saya memahaminya dengan benar? Token akses tidak pernah mencapai mesin pengguna akhir?
divyanshm

1
Token akses tidak pernah mencapai mesin pengguna akhir? ya, itu terkait dengan profil Anda dengan server aplikasi klien.
Bassem Reda Zohdy

4

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/


1
Terima kasih untuk tautan itu, itu membantu saya memahami perbedaan antara setiap jenis hibah dan kapan harus memilih masing-masing.
François POYER

3

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


2

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.

2

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


1

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.


0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.