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
