Hi dear Fineract community, As part of FINERACT-1908 <https://issues.apache.org/jira/browse/FINERACT-1908>, I’d like to share some exciting plans regarding the upcoming revamp of our OAuth functionality, which is currently outdated and based on deprecated components.
We are working to replace the existing custom OAuth code with modern, Spring-based solutions that support OAuth 2.1 and PKCE. Our approach will leverage the following Spring modules: Resource server: spring-boot-starter-oauth2-resource-server OAuth2 client: spring-boot-starter-oauth2-client Authorization server (drop-in default): spring-boot-starter-oauth2-authorization-server Default Behavior By default, Fineract will act as both: An authorization server, and A resource server However, this default setup will be configurable. You’ll be able to disable the built-in authorization server and instead integrate with third-party solutions such as Keycloak or any other OAuth-compliant provider. Having a default authorization server ensures that Fineract can run standalone without relying on external tools to support the full OAuth flow. We will configure OAuth 2.1 with PKCE in a way that fits well into the Fineract architecture and provides strong security by default. 📖 More about this flow: https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce 🧭 Example flow diagram: Phase 1 Deliverables We aim to complete the following in the first phase: Remove custom OAuth components (e.g. OauthAuthenticationProvider, etc.) Remove outdated and unmaintained Apache Oltu dependencies Integrate a minimal Spring Authorization Server configuration (as a default part of Fineract) Support OAuth 2.1 Authorization Code flow with PKCE Provide a minimal login page to authenticate users using: tenant identifier + username + password Authentication Details During authorization, when Fineract acts as the authorization server, the m_appuser table will be queried to validate credentials. The resulting access token will include both the tenant identifier and username. When Fineract acts as a resource server, it will validate the token and resolve the authenticated user by looking up the relevant AppUser in the database. Roles and permissions will (for now) continue to be handled internally by Fineract based on the logged-in user and tenant context. For full context and tracking, please see the related JIRA tickets: FINERACT-1908 <https://issues.apache.org/jira/browse/FINERACT-1908> FINERACT-1984 <https://issues.apache.org/jira/browse/FINERACT-1984> Looking forward to your feedback, thoughts, and any suggestions you may have! Best regards, Adam
