Alur OAuth 2.0 dan Jenis Token

OAuth 2.0 mendefinisikan empat peran. Pemilik Sumber Daya adalah pengguna yang memiliki data, misalnya berkas Google Drive miliknya. Klien adalah aplikasi yang meminta akses. Server Otorisasi menerbitkan token akses, misalnya server OAuth milik Google. Server Sumber Daya menyimpan data yang dilindungi, misalnya Google Drive API. Memahami peran-peran ini memperjelas tujuan setiap alur.

Alur kode otorisasi adalah alur yang tepat untuk aplikasi web sisi server. Pengguna melakukan autentikasi di server otorisasi, yang kemudian mengarahkan pengguna kembali ke klien dengan kode otorisasi berumur pendek. Server klien menukarkan kode ini dengan token melalui permintaan melalui saluran belakang. Token tidak pernah melewati peramban, sehingga terlindung dari kebocoran melalui riwayat peramban dan perujuk.

Alur implisit dirancang untuk aplikasi JavaScript khusus peramban yang tidak dapat menyimpan rahasia klien secara aman. Token dikembalikan langsung di fragmen URL sehingga melewati saluran belakang. Alur implisit tidak lagi digunakan dalam OAuth 2.1 karena PKCE (RFC 7636) memungkinkan klien publik menggunakan alur kode otorisasi secara aman tanpa rahasia klien.

Alur ROPC memungkinkan klien mengumpulkan nama pengguna dan kata sandi pengguna secara langsung, lalu menukarkannya dengan token. Alur ini ditujukan untuk klien pihak pertama yang sangat tepercaya, tetapi pada dasarnya menggagalkan tujuan OAuth untuk mencegah aplikasi melihat kredensial pengguna. Alur ini tidak lagi digunakan dalam OAuth 2.1 dan tidak boleh digunakan dalam aplikasi baru apa pun.

Alur kredensial klien digunakan untuk autentikasi mesin-ke-mesin (M2M) ketika tidak ada pengguna yang terlibat. Klien melakukan autentikasi langsung ke server otorisasi menggunakan ID dan rahasianya, lalu menerima token akses untuk digunakan sendiri. Kasus penggunaan umum meliputi tugas latar belakang, komunikasi antarlayanan mikro, dan gerbang API yang mengakses layanan sisi belakang.

Alur otorisasi perangkat (RFC 8628) memungkinkan penggunaan OAuth pada perangkat dengan kemampuan masukan terbatas, seperti TV pintar, konsol permainan, printer, dan perangkat IoT. Perangkat menampilkan kode singkat dan URL. Pengguna mengunjungi URL tersebut melalui ponsel atau komputer untuk memberikan otorisasi. Perangkat memeriksa server otorisasi secara berkala sampai pengguna menyelesaikan otorisasi.

OAuth 2.0 mendefinisikan dua jenis token akses. Token opak adalah rangkaian karakter acak yang divalidasi oleh server sumber daya dengan memanggil titik akhir introspeksi server otorisasi. Token akses JWT bersifat mandiri: server sumber daya dapat memvalidasinya secara lokal dengan memverifikasi tanda tangan, sehingga mengurangi panggilan API introspeksi, tetapi memerlukan pengelolaan kunci.

Token penyegaran adalah kredensial berumur panjang yang digunakan untuk memperoleh token akses baru setelah token akses kedaluwarsa. Rotasi token penyegaran, yang diwajibkan dalam OAuth 2.1 untuk klien publik, menerbitkan token penyegaran baru setiap kali digunakan dan membuat token lama tidak berlaku. Jika token penyegaran yang dicuri digunakan, klien yang sah mendeteksi bahwa token tersebut tidak lagi berlaku, sehingga memungkinkan pendeteksian pencurian token.

RFC 7662 mendefinisikan titik akhir introspeksi token, yang memungkinkan server sumber daya menanyakan status terkini token akses opak kepada server otorisasi, termasuk status aktif atau tidak aktif, cakupan, subjek, dan waktu kedaluwarsa. Introspeksi memungkinkan pencabutan token secara waktu nyata: setelah token dicabut di server otorisasi, panggilan introspeksi segera mengembalikan active: false.

RFC 7009 mendefinisikan titik akhir pencabutan token, yang memungkinkan klien memberi tahu server otorisasi bahwa token, baik token akses maupun token penyegaran, harus dibuat tidak berlaku. Fitur ini digunakan saat pengguna keluar atau ketika klien mendeteksi aktivitas mencurigakan. Token akses JWT tidak dapat dicabut sepenuhnya tanpa daftar pencabutan, karena server sumber daya memvalidasinya secara lokal tanpa menghubungi server otorisasi.

Cakupan OAuth 2.0 mendefinisikan izin khusus yang diminta klien. Server otorisasi menampilkan cakupan yang diminta kepada pengguna untuk disetujui. Server sumber daya menerapkan persyaratan cakupan pada setiap titik akhir. Prinsip hak istimewa minimum berlaku: klien sebaiknya hanya meminta cakupan minimum yang diperlukan, dan server sumber daya sebaiknya menolak permintaan dengan cakupan yang tidak memadai.

Alur kode otorisasi tepat untuk aplikasi sisi server. Alur implisit tidak lagi digunakan, jadi gunakan PKCE. Alur ROPC tidak lagi digunakan karena menghilangkan tujuan OAuth. Kredensial klien melayani M2M. Otorisasi perangkat menangani perangkat dengan masukan terbatas. Token akses dapat berupa token opak atau JWT. Token penyegaran sebaiknya dirotasi. Introspeksi (RFC 7662) dan pencabutan (RFC 7009) melengkapi pengelolaan token.