Hi Alberto, Thank you for the proposal and the initial information.
Before we proceed with voting, I’d like to clarify a few points: Automated User and Role Assignment I’m not particularly fond of the idea of automating user creation and role assignments. I can’t help but wonder how it could be abused if enabled or why we should even have something like that for Fineract. I understand the convenience it offers, but I believe we need to be strict and explicit in implementing multiple validations to prevent accidental privilege escalation or ensuring those who shouldn’t have access are not granted access to Apache Fineract. Considering Fineract is a core financial system, access and roles should be limited and strictly audited. I simply don’t see the need for automation in registering users and providing access. I wonder what the community thinks about this. Lookup by username vs email address This part looks fine, we can have multiple unique identifiers to look up and map JWT token holder to Fineract user account, but again, we need to make sure the validation and look up methods are straightforward and explicit. Multiple providers are listed While I am okay to support multiple providers, but implementation wise, I don’t think we should target more than 1 or 2 at first, and the rest can be implemented based on need. I don’t want to introduce custom implementations into the system without maintainers who are interested in keeping up to date and using it in production. What do you think? Regards, Adam > On May 26, 2026, at 3:22 AM, Jose Alberto Hernandez <[email protected]> > wrote: > > Hello Fineract community, > > I would like to open a vote on FINERACT-2616: OIDC Federation Support for > External Identity Providers > <https://issues.apache.org/jira/browse/FINERACT-2616> > > This allows organizations with an existing corporate IdP (Keycloak, Google > Workspace, Azure AD, Okta, Auth0) to enable SSO without forking > authentication logic or maintaining a parallel user database. The feature is > fully opt-in (fineract.security.oidc-federation.enabled=true) and does not > affect existing Basic Auth or OAuth2 deployments. > > Fineract PR raised <https://github.com/apache/fineract/pull/5883> > > --- > The core of this contribution is OidcAppUserResolutionServiceImpl, which > bridges an external OIDC identity to a Fineract AppUser using a three-step > strategy on every authenticated request: > > 1. Lookup by username — using the configured usernameClaim (default: > preferred_username) > 2. Fallback by email — matches users pre-existing in Fineract by their > corporate email > 3. Auto-creation — when enabled via > fineract.security.oidc-federation.auto-create-user=true, provisions a new > AppUser on first login, assigned to the head office with the configured > defaultRoles merged with any roles extracted from the OIDC token. Throws > OidcUserNotFoundException when auto-create is disabled and no match is found. > --- > Please vote: > > [ ] +1 approve > [ ] +0 no objection > [ ] -1 object because: > > Thank you, > Jose Alberto Hernandez
