Pertanyaan OAuth v2 komunikasi antara otentikasi dan server sumber daya


Saya mengalami beberapa kesulitan memahami cara kerja OAUTH-v2.

Itu Spesifikasi OAuth versi 2 membaca:

  1. Mengakses Sumber Daya yang Dilindungi

    Akses klien dilindungi   sumber daya dengan menghadirkan akses
      token ke server sumber daya. Itu   server sumber daya HARUS memvalidasi
      akses token dan pastikan token belum   kedaluwarsa dan cakupannya mencakup
      sumber yang diminta. Metode   digunakan oleh server sumber daya untuk
      memvalidasi token akses (serta   tanggapan kesalahan apa pun) luar   ruang lingkup spesifikasi ini, tapi   umumnya melibatkan interaksi atau   koordinasi antara sumber daya   server dan otorisasi
      server
    .

Bagaimana interaksi antara server sumber daya dan server otorisasi ini bekerja dalam praktik?

  • Bagaimana server sumber daya menentukan bahwa token akses itu diterima valid?
  • Bagaimana server sumber daya mengekstraksi yang diizinkan ruang lingkup dari token untuk melihat apakah akses harus diberikan kepada sumber daya tertentu? Apakah Scope dikodekan dalam token akses, atau apakah server sumber daya harus terlebih dahulu menghubungi server otorisasi?
  • Bagaimana kepercayaan antara server sumber daya dan server otorisasi didirikan?

Mengakses atribut token dan   metode yang digunakan untuk mengakses dilindungi   sumber daya di luar ruang lingkup ini   spesifikasi dan ditentukan oleh   spesifikasi pendamping.

Dapatkah seseorang memberi contoh untuk atribut token?


76
2018-06-06 16:28


asal


Jawaban:


Alasan mengapa ini diluar ruang lingkup spesifikasi adalah berbagai cara untuk mencapai hubungan antara dua entitas ini. Pertanyaan utamanya adalah seberapa kompleks penyebaran Anda.

Misalnya, apakah Anda memiliki satu server yang mengelola otentikasi dan akses, dan satu set layanan terpisah masing-masing dengan servernya sendiri yang melayani panggilan API? Atau, apakah Anda hanya memiliki satu kotak dengan satu server web yang menangani otentikasi / otorisasi dan panggilan API?

Dalam kasus satu kotak, tidak banyak yang diperlukan sebagai token penerbit entitas adalah sama dengan yang memvalidasinya. Anda dapat mengimplementasikan token untuk menggunakan kunci tabel basis data dan mencari catatan dalam database (atau cache memori) pada setiap permintaan, atau Anda dapat menyandikan ruang lingkup, id pengguna dan informasi lainnya langsung ke token dan mengenkripsi menggunakan simetris atau asimetris algoritma.

Hal-hal menjadi sedikit lebih rumit ketika berhadapan dengan lingkungan terdistribusi, tetapi tidak banyak. Anda masih mengeluarkan token di server otorisasi, tetapi server sumber daya memerlukan cara untuk memvalidasi mereka. Hal ini dapat dilakukan dengan membuat API internal yang tersedia untuk server sumber daya untuk meminta server otorisasi untuk "menyelesaikan" token (yang dapat menjadi cepat di lingkungan lokal), atau keduanya dapat membentuk pasangan kunci publik / privat atau rahasia simetris. dan menggunakannya untuk mengenkripsi semua kebutuhan server sumber daya ke token.

Token mandiri lebih panjang tetapi menawarkan kinerja per permintaan yang jauh lebih baik. Namun, mereka datang dengan harga - Anda tidak dapat benar-benar mencabutnya saat mereka masih berlaku (belum kedaluwarsa). Untuk alasan ini, token yang disimpan harus berumur sangat pendek (apa pun yang dapat Anda terima untuk membiarkan akses terbuka setelah dicabut - misalnya banyak situs menggunakan satu jam), dengan penyegaran token yang bagus selama satu tahun atau lebih untuk mendapatkan token baru.


77
2018-06-20 18:39



Salah satu contoh sumber daya - untuk API server otorisasi adalah satu di Situs Web Pengembang Google.
Itu tidak menentukan format token akses, tetapi responsnya tampak cukup bermanfaat secara universal.


4
2017-12-20 07:59