Speaking for myself.... my idea with creating this ticket is that the BFF should have its own authorization server and a user database separate from the fineract user. That implies some design decisions that the GSOC student should try to resolve as part of the project. Maybe you have ideas we haven't considered.
To be clear - the BFF is for the END-USER (customer or client), not the user in the system (back office user). Unless and until fineract has implemented ABAC (attribute based access control) in addition to the the built in RBAC (role based access control), this external end-user database pattern is likely the preferred path. There are other efforts to figure out this problem and I do not mean to step on those toes. However, when Fineract removed the Self-Service APIs from our release, we deliberately removed the pattern that created potential security vulnerabilities, which also removed an important area of functionality. This POC should not re-introduce those concerns. Since this is a proof of concept (POC) and not intended for production, we want to clarify that it represents a usable pattern or one that could lead to future architectural changes or work. A POC should allow for exploration of the solution space with a relatively small investment in time and effort (small being relative to teams of people working over many months or years). An advantage of working on a separate component here is that it can enable forward progress without changes to Fineract. This separation of concerns is an advantage. You may want to examine the previously designed but abandoned fineract-CN project which included this separation. On Thu, Mar 5, 2026 at 1:03 AM Edward Kang <[email protected]> wrote: > Hi Ashar, thanks for the comment in the Matrix chat. As you know, I am > working on this proposal as well for GSoC 2026. I'm leaning towards keeping > the BFF's auth layer separate from Fineract's OAuth2, but it's a good > question for the mentors. Looking forward to discussing it with them! > > Best, > Edward > > On Wed, Mar 4, 2026 at 12:25 PM Ashhar Ahmad Khan <[email protected]> > wrote: > >> Hi everyone, >> >> While thinking through the BFF auth design for FINERACT-2439, I noticed >> that FINERACT-1984 is already marked Fixed targeting 1.13.0 - meaning the >> develop branch now ships with Spring Authorization Server built in and >> Fineract can act as its own OAuth 2.1 authorization server. >> >> That changes the BFF auth question a bit. The way I see it there are two >> directions: the BFF registers itself as an OAuth client against Fineract's >> own authorization server, or it keeps a completely separate identity layer >> and calls Fineract purely as a downstream resource server using a dedicated >> service account. The first is simpler but it ties consumer auth to >> Fineract's m_appuser model - which is exactly what the old self-service >> module did wrong. The second keeps the boundary clean but means running two >> auth layers. >> >> Is there a preferred direction here, or is this one of the open design >> questions the POC is meant to explore? >> > > > -- > Edward E. Kang > [email protected] > 972-768-6940 >
