You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Understanding of current Keycloak integration in email verification flow
Awareness of frontend & backend API payload structure
Summary
Currently, for email verification (i.e., user signup), we are sending encrypted clientId and clientSecret from the frontend. These values determine which Keycloak client to use for user registration.
Instead of passing credentials from the frontend, this proposal suggests using a public clientAlias (e.g., "Sovio", "Educreds", "Verifier") and resolving actual credentials on the backend.
Why this change?
Simplifies the API for consumers (especially those using Swagger/OpenAPI).
Removes the need to encrypt credentials on the frontend.
Enables storing sensitive client credentials securely on the backend (e.g., Supabase Vault).
Reduces security risks related to handling and transmitting secrets from the frontend.
Improves usability by exposing only a user-friendly client identifier (clientAlias) via dropdown or enum in API documentation.
Prerequisites
Summary
Currently, for email verification (i.e., user signup), we are sending encrypted
clientId
andclientSecret
from the frontend. These values determine which Keycloak client to use for user registration.Instead of passing credentials from the frontend, this proposal suggests using a public
clientAlias
(e.g., "Sovio", "Educreds", "Verifier") and resolving actual credentials on the backend.Why this change?
clientAlias
) via dropdown or enum in API documentation.Proposed Payload Change
Current Payload:
Proposed Payload:
Or
client
as a parameterSteps to Reproduce (Current Flow)
Current Behavior
Expected Behavior
Environment
The text was updated successfully, but these errors were encountered: