🔥👍🔥

This is awesome!  Thanks
Paul

On Thu, Sep 11, 2025 at 5:53 AM Ádám Sághy <[email protected]> wrote:

> Dear Fineract Community,
>
> We are pleased to share that the first stage of implementing OAuth 2.1
> with PKCE in Fineract has been completed. A special thanks goes to *Csenge
> Soti*, who carried out the majority of the implementation.
>
> *Kindly review the following PR:*
>  https://github.com/apache/fineract/pull/5028
>
> *Key changes included in this PR:*
> • Removal of custom OAuth components (e.g., OauthAuthenticationProvider)
> • Removal of outdated and unmaintained Apache Oltu dependencies
> • Integration of a minimal Spring Authorization Server configuration as a
> default part of Fineract
> • Support for OAuth 2.1 Authorization Code flow with PKCE
> • Introduction of a minimal login page, allowing authentication via
> tenant identifier, username, and password
>
> *Additional improvements delivered in this stage:*
> • Removal of the deprecated InsecureTwoFactorFilter workaround
> • Alignment of filters and features previously available only for HTTP
> Basic authentication, including:
> • Geolocation filter
> • Loan COB filter
> • Business date filter
> • Idempotency filter
> • Correlation ID filter
>
> *Potential next steps:*
> • Introduce further configuration and extensibility options, such as:
> • CSRF and CORS settings
> • Third-party authorization server support
> • Confidential client authentication
> • Potential OpenID support
>
> We would be happy to collaborate with and welcome contributions from the
> community on these next items. Your feedback, ideas, and participation will
> be invaluable in shaping the continued development of OAuth 2.1 support in
> Fineract.
>
> Regards,
> Adam
>
> Sent from my iPhone
>
> On 30 Jul 2025, at 14:16, Ádám Sághy <[email protected]> wrote:
>
> 
>
> 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: [image: PKCE flow]
>
> ------------------------------
> 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
>
>

-- 
--
Paul

Reply via email to