Apa saja Alur Otorisasi yang pernah ada ?

Alur Otorisasi bermacam-macam. Alur dengan username/password, token based, session based, cookie base, sms auth (otp), biometric, dll.

Semuanya merupakan alur dan metoda otorisasi yang tersedia dan bisa digunakan.

Di OAuth 2 ini flow seperti apa yang dihandle ?

OAuth 2 sendiri ditujukan agar bisa berkembang dan di- extends dengan flow yang baru.

Awalnya alur flow nya cuma ada 4, tetapi kemudian berkembang terus sesuai dengan kebutuhan otorisasi yang ada.

Oleh karena itu ada beberapa flow yang tidak tercantum di spesifikasi OAuth 2 awal RFC 6749.

Tetapi dimunculkan di draft atau document RFC yang baru, seperti untuk Native-app atau dengan PKCE

Jadi apa saja alur / flow OAuth 2 ?

  1. Authorization Code Flow

    Flow ini adalah flow yang paling umum, biasanya digunakan untuk mendapatkan akses ke sumber daya di website umum lain seperti Facebook, Gmail, dll. Flow ini bisa digunakan di aplikasi web, mobile apps, single page application.

    Flow ini biasa digunakan ketika tingkat kepercayaan antara aplikasi client dengan API/microservice tidak tinggi atau biasa saja, sehingga diperlukan proses otorisasi yang cukup ketat.

    Flownya menggunakan fungsi redirect halaman login ke halaman login server otorisasi, misalnya Facebook, Gmail, dll. Kemudian pengguna login di halaman tersebut, lalu setelah berhasil login, akan di redirect lagi ke halaman aplikasi client.

  2. Authorization Code Flow dengan PKCE

    Flow ini adalah flow tambahan di atas flow Authorization Code.

    Biasanya digunakan untuk menambahkan tingkat keamanan ketika melakukan pertukaran key/authorization code antara aplikasi client yang bersifat public (aplikasi di browser, SPA, dll) dengan server otorisasi.

    Seperti Authorization Code Flow di point 1 diatas, maka Flow ini bisa digunakan di aplikasi web, mobile apps, single page application.

    Flow ini sama dengan flownya Authorization code, tetapi dengan menambahkan 3 hal berikut ketika melakukan pertukaran key :

    • code verifier
    • code challenge
    • code challenge method.
  3. Device Flow

    Flow ini adalah flow untuk aplikasi yang browserless, seperti android tv, apple tv, voice assistant, dll. Otentikasinya dilakukan dengan device nya dan bantuan aplikasi browser di handphone atau PC kita.

  4. Client Credential Flow

    Flow ini adalah flow otorisasi antara server to server, atau machine to machine, yang tidak akan melibatkan interaksi dari pengguna. Otorisasi ini adalah antara 2 entitas server yang saling trust satu sama lain.

    Misalnya otorisasi antara backend sebuah aplikasi dengan backend aplikasi lain, yang tidak membutuhkan otorisasi dari pengguna/user.

    Biasanya ini membutuhkan clientId dan client secret dalam berkomunikasi antara mesin client dengan server otorisasi.

  5. Implicit Flow

    Flow ini biasanya digunakan untuk native app dan aplikasi berbasis javascript.

    Implicit flow mirip dengan Authorization Code Flow, tetapi dilakukan secara lebih sederhana. User akan diarahkan ke server otorisasi, server otorisasi akan menampilkan form login, lalu user akan login, dan server otorisasi akan mengembalikan access token langsung setelah usernya terotorisasi. Tidak ada proses tambahan menvalidasi code setelah user berhasil login.

    Flow ini ditujukan sebelumnya untuk native app dan aplikasi berbasis javascript, dengan pertimbangan tidak ada gunanya menambahkan code challenge setelah user berhasil login, karena native app dan javascript tidak bisa menyimpan secara aman codenya/secret code disisi client/browser.

    Walaupun sebenarnya tingkat kepercayaan antara aplikasi client dengan API/microservice juga tidak tinggi atau biasa saja.

    Flow ini sudah tidak direkomendasikan, karena terdapat celah keamanan didalamnya.

  6. Password Grant

    Flow ini adalah flow yang paling sederhana. Hampir mirip dengan form login di aplikasi client, berisikan input untuk username dan password.

    Flow ini cocok untuk aplikasi yang server otorisasinya sama atau merupakan bagian dari aplikasi yang sama dengan service/API. Dengan kata lain tingkat kepercayaan antara aplikasi client dan server otorisasi tinggi sekali.

    User akan login di aplikasi client menggunakan form login aplikasi client. Aplikasi client kemudian akan berkomunikasi dengan server otorisasi untuk mendapatkan akses token. Tergantung dari batas waktu expired token nya, maka komunikasi selanjutnya akan memakai access token tersebut.

    Flow ini juga sekarang sudah tidak direkomendasikan. Tetapi sebelumnya diizinkan, karena tujuannya sebenarnya adalah agar komunikasi antara pengguna dan API tidak lagi memakai HTTP Basic Authentication atau username password , tetapi lebih kepada memakai token.