Apa Itu OAuth? - API7.ai

Membuat akun baru untuk berbagai situs web yang berbeda selalu menjadi hal yang merepotkan. Sebagian besar dari proses tersebut adalah pekerjaan yang berulang, karena semuanya mengandung informasi pengguna yang sama, seperti nama dan nomor telepon.

“Apakah mungkin mengizinkan aplikasi mengakses data saya tanpa harus memberikan kata sandi saya?”

OAuth adalah standar yang mencoba menyelesaikan masalah ini dengan menyediakan otorisasi terpusat.

OAuth, yang merupakan singkatan dari “Open Authorization,” adalah standar terbuka untuk delegasi akses. Ini memungkinkan Anda (pemilik sumber daya) untuk berbagi informasi antara aplikasi dan situs web tanpa mengekspos kata sandi Anda. OAuth digunakan secara luas, dan Anda mungkin menggunakan layanan OAuth setiap hari. Misalnya, untuk masuk ke GeeksforGeek, Anda dapat memilih untuk masuk menggunakan akun Google Anda. Dengan melakukan ini, Anda mengizinkan GeeksforGeek untuk mengakses beberapa informasi di akun Google Anda, seperti nama pengguna, foto profil, dll.

Contoh Masuk dengan OAuth

Sejarah OAuth

Protokol OAuth 1.0 diterbitkan sebagai RFC 5849, sebuah Request for Comments informasional, pada April 2010.

Protokol OAuth 2.0 diterbitkan sebagai RFC 6749, dan Penggunaan Token Bearer OAuth 2.0 diterbitkan sebagai RFC 6750, pada Oktober 2012.

Meskipun dibangun berdasarkan pengalaman penerapan OAuth 1.0, OAuth 2.0 adalah penulisan ulang total dari OAuth 1.0 dari awal, hanya berbagi tujuan keseluruhan dan pengalaman pengguna secara umum. OAuth 2.0 tidak kompatibel dengan OAuth 1.0.

Cara Kerja OAuth 2.0

Dalam protokol OAuth, alih-alih menggunakan nama pengguna dan kata sandi pemilik sumber daya untuk mengakses sumber daya yang dilindungi, klien menggunakan token akses. Klien memperoleh token akses dari server otorisasi setelah persetujuan dari pemilik sumber daya. Agar pemilik sumber daya memberikan otorisasi kepada klien, ia harus terlebih dahulu diautentikasi pada aplikasi. Dan karena autentikasi hanya terjadi antara pemilik sumber daya dan aplikasi, klien pihak ketiga tidak dapat mengetahui informasi pribadi apa pun dari pemilik sumber daya.

Kita dapat melihat bahwa menerapkan protokol OAuth akan sangat menyederhanakan proses autentikasi klien pihak ketiga. Yang perlu dilakukan hanyalah mendapatkan otorisasi dari pengguna, meminta token akses, menggunakannya, dan mendapatkan informasi pengguna (sumber daya yang dilindungi). Ini tidak memerlukan pengguna baru untuk mendaftarkan akun atau mengekspos kredensial mereka, sehingga mengurangi area serangan dan meningkatkan keamanan jaringan.

Perlu dicatat bahwa OAuth bukanlah autentikasi. Auth di sini adalah otorisasi. Pengguna tidak masuk ke aplikasi. Ia hanya mengizinkan aplikasi pihak ketiga untuk mendapatkan beberapa informasinya.

Proses Otorisasi OAuth

Peran

OAuth mendefinisikan empat peran:

Klien - Aplikasi yang ingin mengakses data Anda (pemilik sumber daya) dan membuat permintaan sumber daya yang dilindungi atas nama pemilik sumber daya dan dengan otorisasinya.

Pemilik sumber daya - Pengguna yang memiliki data di server sumber daya, ingin menggunakan layanan klien dan memiliki akun di server otorisasi. Misalnya, saya adalah pemilik sumber daya dari profil Facebook saya, dan saya ingin menggunakan layanan GeeksforGeeks.

Server otorisasi - Mesin utama OAuth. Mengeluarkan token akses ke klien setelah berhasil mengautentikasi pemilik sumber daya dan mendapatkan otorisasi.

Server sumber daya - Server yang menyimpan data yang diinginkan klien, mampu menerima dan merespons permintaan sumber daya yang dilindungi menggunakan token akses.

Alur Protokol OAuth

alur protokol oauth

Langkah A: Aplikasi pihak ketiga meminta otorisasi dari pengguna

Langkah B: Aplikasi pihak ketiga menerima pemberian otorisasi, yang merupakan kredensial yang mewakili otorisasi pemilik sumber daya

Langkah C: Aplikasi pihak ketiga meminta token akses menggunakan pemberian otorisasi

Langkah D: Server otorisasi mengautentikasi klien dan memvalidasi pemberian otorisasi, jika valid, ia mengeluarkan token akses ke aplikasi pihak ketiga

Langkah E: Aplikasi pihak ketiga menggunakan token akses untuk meminta sumber daya yang dilindungi dari server sumber daya

Langkah F: Server sumber daya memvalidasi token akses dan melayani permintaan jika valid

Kode Otorisasi dan Token Akses

Ada empat jenis pemberian otorisasi untuk mendapatkan token akses dari server otorisasi. Di sini kita hanya akan membahas metode Authorization Code, karena ini adalah metode yang paling aman dan paling umum.

alur oauth - mode kode otorisasi

Langkah A: Aplikasi pihak ketiga membiarkan pengguna memilih metode otorisasi, seperti GitHub, dan kemudian mengarahkan pengguna ke server otorisasi dengan parameter seperti client_id dan redirect_uri

Contoh permintaan:

    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

Langkah B: Pengguna masuk dan memberikan otorisasi

Langkah C: Server otorisasi mengarahkan pengguna kembali ke backend aplikasi pihak ketiga sesuai dengan redirect_uri, memberikan kode otorisasi

Contoh respons:

     HTTP/1.1 302 Found
     Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
               &state=xyz

Langkah D: Aplikasi pihak ketiga menggunakan kode otorisasi untuk menukar token akses dari server otorisasi

Contoh permintaan:

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
     &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Langkah E: Server otorisasi memvalidasi dan mengembalikan token akses

Contoh respons dari server otorisasi:

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

Contoh Nyata

Bob ingin mencetak pesanan Amazon-nya dengan rapi menggunakan perangkat lunak bernama Rabbit.

Pemilik sumber daya -> Bob

Klien (aplikasi pihak ketiga) -> Perangkat lunak Rabbit

Server otorisasi -> Server otorisasi Amazon

Server sumber daya -> Basis data Amazon untuk menyimpan informasi pesanan

Sumber daya yang dilindungi -> Informasi pesanan Bob di Amazon

Contoh Alur OAuth - Pesanan Amazon

Mengapa Kode Otorisasi dan Token Akses Harus Diperoleh Secara Terpisah?

Kode otorisasi dan token akses diperoleh secara terpisah untuk memastikan langkah-langkah keamanan.

Dalam protokol OAuth2, kode otorisasi adalah kode sementara yang akan ditukar klien dengan token akses. Kode ini diperoleh dari server otorisasi, di mana pengguna (pemilik sumber daya) memiliki kesempatan untuk melihat informasi apa yang diminta klien dan menyetujui atau menolak permintaan tersebut.

Setelah pengguna masuk dan memberikan otorisasi dengan sukses, mereka diarahkan kembali ke aplikasi dengan kode otorisasi sementara di URL.

Kode otorisasi ini umumnya berlaku selama sepuluh menit dan hanya sekali. Masa berlaku yang singkat mengurangi risiko kebocoran informasi pengguna jika dicuri. Sebaliknya, masa berlaku access_token relatif lama, biasanya 1 hingga 2 jam. Jika bocor, ini dapat menimbulkan bahaya yang lebih besar bagi keamanan data pengguna.

Selain itu, untuk menukar token akses, klien perlu menyediakan client ID dan client secret selain kode otorisasi. Server otorisasi memerlukan parameter ini untuk mengautentikasi klien dan memeriksa bahwa yang meminta token akses adalah pihak yang dapat dipercaya. Jika kode otorisasi bocor, tetapi peretas tidak memiliki client ID dan client secret, ia tetap tidak akan dapat memperoleh kode akses. Bahkan jika ia memiliki client ID dan client secret, ia masih harus bersaing dengan server klien, karena kode otorisasi hanya berlaku sekali. Mekanisme ini secara signifikan meningkatkan kesulitan serangan potensial. Jika kita melewatkan langkah memperoleh kode otorisasi dan langsung mengembalikan token akses, penyerang dapat dengan mudah menggunakan token akses untuk mencuri informasi pengguna.

OIDC (OpenID Connect)

Apa tujuan menggunakan OAuth untuk otorisasi? Ini untuk mendapatkan berbagai informasi tentang pengguna. Mengapa kita tidak bisa menstandarisasi output sehingga aplikasi pihak ketiga dapat menggunakannya langsung?

OIDC melakukan standarisasi ini.

Bagaimana OIDC melakukannya? Secara sederhana, ia mengembalikan id_token format JWT tambahan yang berisi informasi dasar pengguna bersama dengan access token. Aplikasi pihak ketiga dapat memperoleh informasi pengguna dengan memeriksa algoritma penandatanganan dan memverifikasi tanda tangan pada id_token dengan kunci publik.

Selain itu, OIDC menyediakan endpoint UserInfo. Layanan pihak ketiga dapat menggunakan token akses untuk mengakses endpoint ini untuk mendapatkan informasi tambahan tentang pengguna.

Fitur lain dari OIDC adalah Single Sign On (SSO) dan Single Log Out (SLO). SSO meningkatkan kegunaan dengan memungkinkan pengguna memiliki sesi yang diautentikasi dengan klien yang berbeda tanpa harus memberikan kredensial setiap kali. Selama pengguna berhasil masuk ke satu aplikasi, tidak perlu memasukkan kata sandi lagi saat masuk ke aplikasi lain.

SLO meningkatkan keamanan dengan memastikan tidak ada sesi aktif yang tersisa dari sesi SSO setelah pengguna memulai logout tunggal. Pengguna hanya perlu logout sekali dan semua sesi akan dihentikan, mencegah mereka dari peretasan atau penyalahgunaan.

Perlu dicatat bahwa OIDC tidak menstandarisasi metode autentikasi tertentu, seperti kata sandi atau pengenalan wajah. Sebaliknya, ini menentukan cara mendelegasikan autentikasi ke penyedia autentikasi terpusat, apa yang kita dapatkan setelah autentikasi - id token, bagaimana token ini diverifikasi - format JWT, dan informasi pengguna apa yang terkandung dalam id token ini. Jadi, aplikasi pihak ketiga tidak perlu lagi menciptakan roda.

Dukungan APISIX untuk OAuth/OIDC

Apache APISIX adalah gateway API cloud-native sumber terbuka. Ini adalah gateway API yang dinamis, real-time, dan berkinerja tinggi, dan Anda dapat menggunakannya untuk menangani lalu lintas utara-selatan tradisional, serta lalu lintas timur-barat antara layanan. Ini juga dapat digunakan sebagai kontroler ingress k8s.

Karena APISIX adalah gateway API yang bertindak sebagai proxy untuk beberapa server aplikasi upstream, sangat wajar untuk menempatkan otorisasi terpusat dan autentikasi pada gateway API.

Plugin OpenID Connect (OIDC) APISIX mendukung protokol OpenID Connect. Pengguna dapat menggunakan plugin ini untuk menghubungkan APISIX dengan banyak penyedia identitas (IdP), seperti Okta, Keycloak, Ory Hydra, Authing, dll., dan menerapkannya sebagai gateway autentikasi terpusat. OIDC adalah superset dari OAuth, jadi plugin ini juga mendukung OAuth.

Diagram penerapan:

Diagram penerapan apisix dan oauth

Contoh Konfigurasi: Integrasikan Keycloak untuk Autentikasi dengan Apache APISIX

Konfigurasi Keycloak

Parameter	Nilai
alamat keycloak	http://127.0.0.1:8080/
Realm	myrealm
Tipe Klien	OpenID Connect
ID Klien	myclient
Rahasia Klien	e91CKZQwhxyDqpkP0YFUJBxiXJ0ikJhq
URI Pengalihan	http://127.0.0.1:9080/anything/callback
Discovery	http://127.0.0.1:8080/realms/myrealm/.well-known/openid-configuration
URI Logout	/anything/logout
Nama Pengguna	myuser
Kata Sandi	myrealm
Realm	mypassword

Contoh kode

curl -XPUT 127.0.0.1:9080/apisix/admin/routes/1 -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -d '{
    "uri":"/anything/*",
    "plugins": {
        "openid-connect": {
            "client_id": "myclient",
            "client_secret": "e91CKZQwhxyDqpkP0YFUJBxiXJ0ikJhq",
            "discovery": "http://127.0.0.1:8080/realms/myrealm/.well-known/openid-configuration",
            "scope": "openid profile",
            "bearer_only": false,
            "realm": "myrealm",
            "redirect_uri": "http://127.0.0.1:9080/anything/callback",
            "logout_path": "/anything/logout"
        }
    },
    "upstream":{
        "type":"roundrobin",
        "nodes":{
            "httpbin.org:80":1
        }
    }
}'

Ketika Anda mengunjungi http://127.0.0.1:9080/anything/test setelah API berhasil dibuat, Anda akan diarahkan ke halaman login Keycloak karena Anda belum masuk:

Masukkan myuser sebagai nama pengguna dan mypassword sebagai kata sandi, dan Anda akan diarahkan ke halaman berikut.

diberikan otorisasi apisix keycloak

Kunjungi http://127.0.0.1:9080/anything/logout untuk logout:

logout apisix keycloak

Ringkasan

Singkatnya, standar OAuth adalah solusi populer untuk aplikasi dan pengguna. Ini memberikan kenyamanan dan keamanan dengan memungkinkan pengguna untuk menggunakan layanan di berbagai platform tanpa membagikan kredensial mereka. Apache APISIX adalah gateway API populer yang mendukung integrasi berbagai penyedia identitas (Keycloak, Ory Hydra, Okta, Auth0, dll.) untuk melindungi API Anda.

Baca lebih lanjut: