Task - RBAC AuthZ - Implement AuthZ Utils into frontend-base

[rodmgwgu]

Implement reusable utils to query for permissions from openedx-authz on frontend MFEs.

The utils should include:

• A hook to query for permissions (useUserPermissions), this hook should cache the query result to minimize calls to the backend.
• Types for handling permissions
• Documentation on how to use and best practices.

Most of this was already implemented directly into frontend-app-authoring, see: openedx/frontend-app-authoring#2685

This implementation should be extracted to frontend-base and be reused across MFEs.

[MaferMazu]

Based on my understanding of this issue, the goal is to centralize all permission-related logic and hooks within frontend-base. This would enable easier, more efficient reuse across all Micro-Frontends (MFEs).

However, I believe we still need to refine this.

Is it valuable to move those hooks to frontend-base in the short term? Could we use that to refactor the existing use?

cc @bra-i-am

[bra-i-am]

@MaferMazu: here is the refinement of this task; I'll be modifying the code with Claude's help, and I think the PR will be ready soon

---

Refinement

Goal

Extract the generic permission-validation stack from frontend-app-authoring into @openedx/frontend-base so any MFE can integrate openedx-authz by installing the library and importing the hooks.

---

What to build in frontend-base

runtime/authz/

types.ts

• PermissionValidationRequestItem — shape of a single permission check sent to the backend (action, scope)
• PermissionValidationResponseItem — same shape coming back from the backend, plus allowed: boolean
• PermissionValidationQuery — the key/value map the caller builds ({ canEdit: { action: '...', scope: '...' } }); keys are arbitrary names chosen from the MFE
• PermissionValidationAnswer<Query> — maps every key from the caller's query to a boolean; the generic preserves exact key names so TypeScript catches typos at call sites

api.ts

• PERMISSIONS_VALIDATE_PATH — the endpoint path as a constant so it's never duplicated or hardcoded across files
• validatePermissions(apiBaseUrl, query) — posts the query to the authz service and maps the response array back to the caller's key names; defaults any key the server omits to false

hooks.ts

• permissionsQueryKeys — stable cache key factory so TanStack Query can deduplicate and invalidate permission queries consistently
• UsePermissionsOptions — type for the optional retry override
• UsePermissionsResult — return type of usePermissions; intersection of { isLoading, isAuthzEnabled } and permission keys spread at the top level
• usePermissions(apiBaseUrl, query, featureEnabled = true, options?) — single hook; when featureEnabled is false it skips the API call and returns all keys as true (gradual rollout safe by default); when true it calls the authz API and returns actual server values; permission keys are spread at the top level

---

Take into account

• Base URL is caller-supplied — Hardcoding a URL in the library would couple it to a specific deployment
• featureEnabled: boolean — Waffle flag names and endpoints differ per MFE (enableAuthzCourseAuthoring). The library receives only the resolved boolean
• featureEnabled: false → all keys true, no API call
• Permissions spread at top level — usePermissions returns { isLoading, isAuthzEnabled, ...permissionKeys } via an intersection type. Collision with metadata keys is practically impossible given the canXxx permission naming convention.

[MaferMazu]

Thanks for the refactor @bra-i-am, but before implementing, can you help me answer those questions:

Is it valuable to move those hooks to frontend-base in the short term? Could we use that to refactor the existing use?

[bra-i-am]

@MaferMazu, sorry, I thought those questions were for @rodmgwgu.

Is it valuable to move those hooks to frontend-base in the short term?

I'd say yes, it's valuable. The migration costs in the Authoring MFE would be minimal, and doing it before a second MFE needs AuthZ prevents copy-paste or doing the extraction under time pressure. The only trade-off is if the AuthZ client interface is still evolving, every change goes through a library release cycle instead of a direct edit, as is done now.

Could we use that to refactor the existing use?

Yes. The public API of useCourseUserPermissions (Authoring MFE) stays the same, so changes required must be minimal. The refactor involves moving the types, API functions, and hooks to @openedx/frontend-base and verifying everything keeps working

[MaferMazu]

@bra-i-am, thanks for the update. So let's work on this. With that, we can have more time to review the designs needed to continue the work of M3 of openedx/openedx-authz#284