Manajemen Siklus Hidup Aplikasi

Halaman ini menjelaskan perilaku registered OIDC applications setelah dibuat: field yang dapat diedit, dampak update terhadap OAuth authorization, dampak perubahan scopes atau redirect configuration, dan cara delete bekerja.

Melihat Daftar Aplikasi

Halaman Applications menampilkan registered applications berdasarkan creation date terbaru. Setiap card menampilkan:

• Client name.
• Creation date.
• client_id dengan copy action.
• client_type, ditampilkan sebagai Public PKCE.
• Allowed web origins.
• Redirect paths.
• Derived redirect URIs.
• Selected OIDC scopes.
• Logo upload control.
• Edit action.
• Delete action jika aplikasi tidak system-reserved.

Field yang Dapat Diedit

Admin dapat mengedit field berikut:

Field	Dampak
clientName	Mengubah application display name dan underlying OAuth application name.
clientDescription	Mengubah optional public application metadata.
allowedWebOrigins	Menghitung ulang derived redirect URIs dan browser-safe CORS origins.
redirectPaths	Menghitung ulang derived redirect URIs.
postVerificationRedirectPath	Mengubah OIDC metadata yang dipakai untuk verification continuation.
scopeIds	Mengganti allowed OIDC scope set milik aplikasi.
Logo	Mengubah public logo URL dan underlying OAuth application icon.

Application client_id dan client_type tidak dapat diedit. Aplikasi yang dibuat admin tetap menjadi Public PKCE clients dan tidak pernah menerima client_secret.

Perubahan Redirect Configuration

Saat allowedWebOrigins atau redirectPaths berubah, Muhajir Studio menurunkan full redirect URI set baru dan menyinkronkan set tersebut ke underlying OAuth application.

Contoh:

Allowed web origins	Redirect paths	Resulting redirect URIs
https://app.example.com	/auth/callback	https://app.example.com/auth/callback
https://app.example.com, https://staging.example.com	/auth/callback	https://app.example.com/auth/callback, https://staging.example.com/auth/callback

Setelah perubahan ini, authorization requests harus memakai salah satu redirect URI yang saat ini diturunkan. Callback URL lama berhenti bekerja segera setelah tidak lagi ada di derived set.

Perubahan Scope

Update scopes mengganti scope assignments milik aplikasi. API terlebih dahulu menghapus rows lama dari application_scope, memvalidasi scope IDs baru, lalu memasukkan set baru.

Saat OIDC authorization, dynamic applications memakai configured scopes milik aplikasi. Authorization middleware menulis ulang requested scope value menjadi configured scope set sebelum OIDC provider memproses request.

Dampak praktis:

• Menambahkan scope memungkinkan authorization flows berikutnya memberikan scope tersebut.
• Menghapus scope mencegah authorization flows berikutnya memberikan scope tersebut.
• Access tokens yang sudah ada tidak dicabut oleh normal scope update.
• Jika immediate revocation diperlukan, delete dan buat ulang aplikasi atau implementasikan dedicated revocation operation.

Perubahan Post-Verification Redirect

Update postVerificationRedirectPath menyimpan path di application row dan menyinkronkannya ke OAuth application metadata.

Saat public metadata diminta dengan query parameter redirect_uri, Muhajir Studio memverifikasi bahwa redirect_uri terdaftar untuk client sebelum menggabungkan origin-nya dengan postVerificationRedirectPath. Ini mencegah unregistered origins mengontrol verification continuation.

Jika tidak ada caller redirect_uri, Muhajir Studio hanya dapat menurunkan postVerificationRedirectUri ketika aplikasi memiliki tepat satu allowed web origin.

Perubahan Logo

Mengunggah logo menyimpan public object di bawah application ID dan mengubah:

• clientLogoUrl pada application response.
• Nilai icon pada underlying OAuth application.

Mengunggah logo baru mengganti displayed logo URL. Upload endpoint mewajibkan file, supported image MIME types, dan batas ukuran 2 MiB.

Perilaku Delete

Delete aplikasi adalah operasi destruktif. Untuk non-system applications, delete:

1. Memuat aplikasi berdasarkan id.
2. Menghapus OAuth access tokens untuk clientId aplikasi.
3. Menghapus saved OAuth consents untuk clientId aplikasi.
4. Menghapus underlying OAuth application row.
5. Menghapus application row.
6. Mencoba menghapus stored logo object setelah database deletion berhasil.
7. Mengembalikan 204 No Content saat berhasil.

Confirmation dialog memperingatkan admin bahwa existing OAuth state untuk client ini akan dicabut. Setelah delete, client_id lama tidak boleh lagi dipakai oleh aplikasi pihak ketiga.

Kemungkinan delete responses:

Status	Error	Arti
204	none	Application deleted.
400	INVALID_ID	Path parameter id bukan UUID valid.
403	APPLICATION_PROTECTED	Application system-reserved dan tidak dapat dihapus.
404	NOT_FOUND	Tidak ada application untuk ID tersebut.

Reserved web-admin Application

Admin application client ID adalah system-reserved dan sebaiknya tetap web-admin di semua environment. Gunakan pengaturan deployed admin origin dan redirect URI untuk mengarahkan client ke domain admin production. Client reserved ini terlihat di application management ketika sudah diseed agar admin dapat meninjau metadata-nya, tetapi dilindungi dari deletion.

UI menyembunyikan delete action untuk reserved clients. Backend juga menegakkan aturan ini; mencoba menghapus reserved client mengembalikan:

{
  "error": "APPLICATION_PROTECTED",
  "message": "System-reserved applications cannot be deleted"
}

Reserved-client protection mencakup RESERVED_OIDC_CLIENT_IDS dari @drova/schemas ditambah nilai runtime API WEB_ADMIN_CLIENT_ID.

Error Handling

Application management endpoints mengembalikan structured errors untuk validation dan lifecycle failures umum:

Error	Kapan terjadi
INVALID_BODY	Create atau update payload gagal schema validation.
INVALID_ID	URL id parameter bukan UUID.
UNKNOWN_SCOPE_IDS	Create atau update mereferensikan scope IDs yang tidak ada.
NOT_FOUND	Requested application tidak ada.
APPLICATION_PROTECTED	Delete dicoba untuk reserved application.
FILE_REQUIRED	Logo upload tidak menyertakan file.
FILE_TOO_LARGE	Logo file melebihi 2 MiB.
INVALID_FILE_TYPE	Logo file MIME type tidak didukung.
INTERNAL_ERROR	Unexpected server-side failure.

Catatan Operasional

• Perlakukan redirect configuration updates sebagai potentially breaking changes untuk aplikasi pihak ketiga.
• Bagikan generated client_id dan exact derived redirect URIs kepada developer.
• Jangan membagikan atau mendokumentasikan client_secret; aplikasi yang dibuat admin tidak memilikinya.
• Scope changes memengaruhi authorization flows berikutnya, tetapi normal updates tidak otomatis mencabut access tokens yang sudah diterbitkan.
• Delete dan buat ulang hanya jika Anda memang ingin menginvalidasi client_id lama serta menghapus stored OAuth access tokens dan consents.