Roadmap draft

[osama1998H]

Here are the same ideas rewritten in plain English with engineering-style wording.

High‑level goals

• Bring uniauth closer to what Keycloak and Auth0 offer in terms of session control, customization, MFA, and developer experience, but keep the system lighter and easier to self‑host than full enterprise solutions.[1][2][3][4][5]

---

Feature ideas inspired by Keycloak

1. Session management

   • Add APIs and an admin UI to list active sessions per user, including device, IP, and last activity.
   • Support killing specific sessions or “log out from all devices” for both admins and end users.[2][3]

2. Configurable login flows

   • Model the login flow as a pipeline or state machine (steps like: self‑registration, email verification, password reset, forced password change).
   • Make each step toggleable via config (e.g., enable/disable registration, require verified email before login).[3][2]

3. Theming / templates for auth pages

   • Introduce a theming system for all user‑facing pages (login, register, forgot password, error pages).
   • Allow overriding layout, logo, colors, and copy via config files or a simple template engine instead of forking the code.[6][3]

4. Token mapping / claims configuration

   • Provide a way to configure which user attributes and roles are included in ID and access tokens.
   • Think of it as “token mappers”: map internal user fields/groups to standard or custom claims.[2][3]

5. Roles and groups

   • Implement a basic RBAC model with roles and optional groups.
   • Expose admin APIs/UI to assign roles to users, manage groups, and read them back through tokens.

6. User account console

   • Build a minimal “My Account” UI where users can update profile fields, change password, view active sessions, and (in the future) manage MFA devices.[3][2]

---

Feature ideas inspired by Auth0

1. Hosted “Universal Login” style page

   • Provide a single hosted login page managed by uniauth that can be reused across multiple client apps.[4][5]
   • Allow per‑client branding (logo, primary color, maybe background) driven by client configuration.

2. Extensible identity providers (social logins)

   • Design a pluggable abstraction for identity providers (OIDC/SAML/social).
   • Start with one provider (e.g., Google) and define a common interface: config (client id/secret), scopes, and callback handling.[5][4]

3. Multi‑factor authentication (MFA, TOTP first)

   • Add TOTP‑based MFA (e.g., Google Authenticator) with enroll/verify flows and backup recovery codes.[4][5][3]
   • Store MFA configuration per user and integrate it as an extra step in the login pipeline.

4. Basic security hardening

   • Implement rate limiting on login endpoints and account lockout after N failed attempts within a time window.[5][4]
   • Add security logs/audit events for login failures, lockouts, and MFA actions.

5. Developer experience (DX)

   • Ship minimal SDKs or example clients (not full frameworks) for typical stacks (for example: Node/Express middleware, Laravel middleware, a SPA example using fetch).
   • Document standard auth flows (authorization code with PKCE, refresh tokens) with end‑to‑end examples.[4][5]

6. Hooks / events around auth flows

   • Add a lightweight hook system or webhooks for “pre‑login”, “post‑login”, “post‑registration”, etc.
   • Let integrators attach custom logic (e.g., check email domain, sync to their CRM) without forking uniauth.[5][4]

---

Short priorities list (what to build first)

1. DX and docs first

   • Clean REST API surface, good README, and one backend + one SPA example so devs can integrate uniauth quickly.[4][5]

2. Strong session model

   • Centralized session store, admin/user endpoints to inspect and revoke sessions, and “logout all sessions” support.[2][3]

3. Themed auth pages

   • Config‑driven templates for login/registration so teams can drop in uniauth without touching internals.[6][3]

4. MFA (TOTP + recovery codes)

   • Add a second factor that is simple but gives a big security win.[3][5][4]

5. Pluggable social login with one provider

   • Design the provider abstraction and implement Google first to prove the extension point, then add more over time.[5][4]

مصادر
[1] Keycloak https://www.keycloak.org
[2] Features | keycloak-documentation https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/overview/features.html
[3] Server Administration Guide https://www.keycloak.org/docs/latest/server_admin/index.html
[4] Auth0 in Detail: Features, Architecture, Use Cases, and Modern ... https://hackmd.io/@stories/auth0-guide
[5] Auth0 - Authentication Simplified - Review, Pricing & Features https://b2bsaasmarket.com/tool/auth0
[6] Server Administration Guide https://docs.redhat.com/en/documentation/red_hat_build_of_keycloak/22.0/html-single/server_administration_guide/index
[7] Enabling and disabling features https://www.keycloak.org/server/features
[8] Chapter 1. Red Hat build of Keycloak features and concepts https://docs.redhat.com/en/documentation/red_hat_build_of_keycloak/22.0/html/server_administration_guide/red_hat_build_of_keycloak_features_and_concepts
[9] Getting list of supported and enabled features #31148 keycloak/keycloak#31148
[10] Guides https://www.keycloak.org/guides