Otorisasi melalui kontrol akses

Otorisasi adalah proses pemberian akses ke berbagai bagian dan aset aplikasi web kepada pengguna. Cara umum untuk mengotorisasi pengguna adalah melalui kontrol akses, di mana admin situs mendefinisikan izin apa yang harus diberikan kepada pengguna dan entitas lain untuk mengakses sumber daya tertentu.

Otorisasi tidak boleh disamakan dengan autentikasi, yang merupakan proses memvalidasi bahwa pengguna adalah siapa yang mereka klaim, biasanya dengan menyediakan kredensial akun. Setelah pengguna terautentikasi, proses otorisasi tetap harus dilakukan pada setiap permintaan, untuk memastikan bahwa pengguna memiliki akses ke sumber daya yang diminta.

Saat mengakses aplikasi melalui GraphQL, kita harus memvalidasi apakah pengguna memiliki akses ke elemen yang diminta dari skema. Apakah logika otorisasi harus dikodekan di dalam lapisan GraphQL?

Jawabannya adalah tidak. Seperti yang dijelaskan oleh dokumentasi di graphql.org, logika otorisasi berada di lapisan logika bisnis, dan dari sana diakses oleh GraphQL. Dengan cara ini, aplikasi dapat memiliki satu sumber kebenaran untuk otorisasi (yaitu yang disediakan oleh WordPress):

Gato GraphQL menghormati prinsip ini, mencerminkan (dan, di bawah mesin, mendelegasikan kepada) mekanisme otorisasi yang disediakan oleh WordPress.

​

Kebijakan Kontrol Akses

Di antara berbagai kebijakan kontrol akses yang dapat kita implementasikan untuk aplikasi kita, dua yang paling populer adalah Role-Based Access Control (RBAC) dan Attribute-Based Access Control (ABAC).

WordPress, dan Gato GraphQL, mendukung keduanya.

Dengan Role-Based Access Control kita memberikan izin berdasarkan peran, lalu menetapkan peran tersebut kepada pengguna. Misalnya, WordPress memiliki peran administrator dengan akses ke semua sumber daya, dan peran editor, author, contributor, serta subscriber dengan izin terbatas dalam berbagai tingkatan, seperti mampu membuat dan menerbitkan posting blog, hanya membuatnya, atau hanya membacanya.

Dengan Attribute-Based Access Control izin diberikan berdasarkan metadata yang dapat ditetapkan ke berbagai entitas, termasuk pengguna, aset, dan kondisi lingkungan (seperti waktu hari atau IP pengunjung). Misalnya di WordPress, kapabilitas edit_others_posts digunakan untuk memvalidasi apakah pengguna dapat mengedit posting pengguna lain.

Secara umum, ABAC lebih disukai daripada RBAC karena memungkinkan kita mengonfigurasi izin dengan kontrol yang sangat terperinci, dan izin tersebut tidak ambigu dalam tujuannya.

Misalnya di WordPress, peran editor memiliki kapabilitas edit_others_posts, tetapi kita mungkin ingin mengizinkan seseorang dengan peran author untuk mengedit posting penulis lain, tanpa memberikan seluruh set izin yang diberikan kepada editor (seperti juga menghapus posting penulis lain). Oleh karena itu, memberikan kapabilitas edit_others_posts dan memeriksa kondisi ini lebih tepat daripada memeriksa peran editor.

​

Mendefinisikan Visibilitas

Ketika pengguna tidak memiliki izin untuk mengakses field yang diminta dari skema GraphQL, apa yang seharusnya menjadi pesan kesalahan yang dikembalikan?

Ada dua kemungkinan, sesuai dengan visibilitas yang diinginkan untuk skema: publik atau privat.

Untuk skema publik, skema GraphQL yang diekspos sama untuk semua pengguna, dan setiap field menjelaskan izin apa yang diperlukan untuk mengaksesnya. Saat meminta field yang tidak dapat diakses, pesan kesalahan akan menjelaskan mengapa pengguna tidak diberikan akses.

Untuk skema privat, skema GraphQL disesuaikan untuk setiap pengguna, dan hanya field yang dapat diakses oleh pengguna yang akan diekspos. Saat meminta field yang tidak dapat diakses, pesan kesalahan akan menyatakan bahwa field tersebut tidak ada.

​

Kontrol Akses melalui Antarmuka Pengguna

Di Gato GraphQL, aturan kontrol akses disuntikkan ke dalam skema saat runtime, sebagai konfigurasi yang ditentukan pengguna melalui access control lists. Dengan cara ini, lapisan GraphQL akan segera mencerminkan perubahan kebijakan kontrol akses, tanpa perlu memperbarui kode apa pun atau mengkompilasi ulang skema:

Admin situs mengonfigurasi ACL, dengan memilih:

• Field yang akan divalidasi
• Sebuah aturan untuk divalidasi, dari antara:
  • apakah pengguna harus sudah masuk?
  • apakah pengguna harus sudah keluar?
  • apakah pengguna harus memiliki peran tertentu?
  • apakah pengguna harus memiliki kapabilitas tertentu?
• Konfigurasi spesifik aturan:
  • peran mana?
  • kapabilitas mana?
• Visibilitas:
  • default (yaitu sama dengan yang ditetapkan ke skema)?
  • publik?
  • privat?