Hi James, That clarifies the direction.
Keeping the BFF responsible for end-user identity and calling Fineract through a service account seems like the clean boundary. I'll go through Fineract CN carefully. Since it never reached adoption, I want to understand what prevented it before applying ideas from it to the POC. Ashhar On 2026/03/05 18:23:47 James Dailey wrote: > 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 > > >
