Bagaimana menangani otentikasi dalam arsitektur RESTful Client-Server adalah masalah perdebatan.
Secara umum, ini dapat dicapai, dalam SOA melalui dunia HTTP melalui:
- Autentikasi dasar HTTP melalui HTTPS;
- Cookie dan manajemen sesi;
- Token dalam tajuk HTTP (mis. OAuth 2.0 + JWT);
- Otentikasi kueri dengan parameter tanda tangan tambahan.
Anda harus beradaptasi, atau bahkan lebih baik mencampur teknik-teknik itu, agar sesuai dengan arsitektur perangkat lunak Anda.
Setiap skema otentikasi memiliki PRO dan Kontra sendiri, tergantung pada tujuan kebijakan keamanan dan arsitektur perangkat lunak Anda.
Autentikasi dasar HTTP melalui HTTPS
Solusi pertama ini, berdasarkan pada protokol HTTPS standar, digunakan oleh sebagian besar layanan web.
GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Sangat mudah untuk diimplementasikan, tersedia secara default di semua browser, tetapi memiliki beberapa kelemahan yang diketahui, seperti jendela otentikasi mengerikan yang ditampilkan pada Browser, yang akan bertahan (tidak ada fitur seperti LogOut di sini), beberapa konsumsi CPU tambahan sisi server, dan fakta bahwa nama pengguna dan kata sandi ditransmisikan (melalui HTTPS) ke Server (seharusnya lebih aman untuk membiarkan kata sandi tetap hanya di sisi klien, selama entri keyboard, dan disimpan sebagai hash aman di Server) .
Kami dapat menggunakan Otentikasi Digest , tetapi juga memerlukan HTTPS, karena rentan terhadap serangan MiM atau Putar Ulang , dan khusus untuk HTTP.
Sesi melalui Cookie
Sejujurnya, sesi yang dikelola di Server tidak benar-benar tanpa kewarganegaraan.
Satu kemungkinan bisa mempertahankan semua data dalam konten cookie. Dan, berdasarkan desain, cookie ditangani di sisi Server (Klien, pada kenyataannya, bahkan tidak mencoba untuk menafsirkan data cookie ini: cookie hanya dikembalikan ke server pada setiap permintaan berturut-turut). Tetapi data cookie ini adalah data status aplikasi, jadi klien harus mengelolanya, bukan server, di dunia Stateless murni.
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
Teknik cookie itu sendiri adalah HTTP-linked, jadi itu tidak benar-benar tenang, yang seharusnya protokol-independen, IMHO. Ini rentan terhadap serangan MiM atau Replay .
Diberikan melalui Token (OAuth2)
Alternatifnya adalah dengan meletakkan token di dalam header HTTP sehingga permintaan dikonfirmasi. Inilah yang dilakukan OAuth 2.0. Lihat RFC 6749 :
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
Singkatnya, ini sangat mirip dengan cookie dan menderita masalah yang sama: tidak stateless, bergantung pada detail transmisi HTTP, dan tunduk pada banyak kelemahan keamanan - termasuk MiM dan Replay - sehingga harus digunakan hanya melalui HTTPS. Biasanya, JWT digunakan sebagai token.
Otentikasi Permintaan
Otentikasi kueri terdiri atas penandatanganan setiap permintaan RESTful melalui beberapa parameter tambahan pada URI. Lihat artikel referensi ini .
Itu didefinisikan seperti itu dalam artikel ini:
Semua kueri REST harus diautentikasi dengan menandatangani parameter kueri yang diurutkan dalam huruf kecil, urutan abjad menggunakan kredensial pribadi sebagai token penandatanganan. Penandatanganan harus terjadi sebelum URL menyandikan string kueri.
Teknik ini mungkin lebih kompatibel dengan arsitektur Stateless, dan juga dapat diimplementasikan dengan manajemen sesi ringan (menggunakan sesi di-memori alih-alih kegigihan DB).
Misalnya, berikut ini adalah sampel URI generik dari tautan di atas:
GET /object?apiKey=Qwerty2010
harus ditransmisikan seperti itu:
GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789
String yang ditandatangani adalah /object?apikey=Qwerty2010×tamp=1261496500dan tanda tangannya adalah hash SHA256 dari string yang menggunakan komponen pribadi dari kunci API.
Caching data sisi server selalu tersedia. Misalnya, dalam kerangka kerja kami, kami menyimpan tanggapan di tingkat SQL, bukan di tingkat URI. Jadi menambahkan parameter tambahan ini tidak merusak mekanisme cache.
Lihat artikel ini untuk beberapa detail tentang RESTful otentikasi dalam kerangka klien-server ORM / SOA / MVC kami, berdasarkan JSON dan REST. Karena kami mengizinkan komunikasi tidak hanya melalui HTTP / 1.1, tetapi juga memberi nama pipa atau pesan GDI (lokal), kami mencoba menerapkan pola otentikasi yang benar-benar tenang, dan tidak bergantung pada kekhususan HTTP (seperti header atau cookie).
Nanti Catatan : menambahkan tanda tangan di URI dapat dilihat sebagai praktik buruk (karena misalnya akan muncul di log server http) sehingga harus dimitigasi, misalnya dengan TTL yang tepat untuk menghindari replay. Tetapi jika log http Anda terganggu, Anda pasti akan memiliki masalah keamanan yang lebih besar.
Dalam praktiknya, Autentikasi Token MAC yang akan datang untuk OAuth 2.0 mungkin merupakan peningkatan besar sehubungan dengan skema saat ini "Diberikan oleh Token". Tapi ini masih dalam proses dan terkait dengan transmisi HTTP.
Kesimpulan
Layak untuk menyimpulkan bahwa REST tidak hanya berbasis HTTP, bahkan jika, dalam praktiknya, itu juga sebagian besar diimplementasikan melalui HTTP. REST dapat menggunakan lapisan komunikasi lainnya. Jadi otentikasi TENANG bukan hanya sinonim dari otentikasi HTTP, apa pun yang dijawab Google. Bahkan seharusnya tidak menggunakan mekanisme HTTP sama sekali tetapi harus diabstraksi dari lapisan komunikasi. Dan jika Anda menggunakan komunikasi HTTP, berkat inisiatif Let's Encrypt, tidak ada alasan untuk tidak menggunakan HTTPS yang tepat, yang diperlukan selain skema otentikasi apa pun.