openmrs-module-authentication config

This TALK thread is a continuation of an earlier conversation visible here

As stated in the earlier thread:

openmrs-module-authentication works perfectly fine alongside the default Authentication mechanism of OpenMRS, but there seems to be an issue when it is used with openmrs-module-oauth2login

According to the README, Authentication module registers a custom DelegatingAuthenticationScheme which delegates to another AuthenticationScheme that is configured at runtime. So, in this case the Authentication mechanism needs to be delegated to OAuth 2.0 Login Module

Further in the README it is said that “Configuring the default scheme is a matter of setting the authentication.scheme configuration property to the schemeId of a configured scheme” & the schemeId here will be the class name of the AuthenticationScheme that should be instantiated. So the class name here will be org.openmrs.module.oauth2login.OAuth2UserInfoAuthenticationScheme

To set the AuthenticationScheme the below lines were added to /var/lib/OpenMRS/


But, in spite of this the Authentication is not happening as expected and the login fails. Looks like further config is needed.

System details: core 2.5.8 with the latest versions of both the modules mentioned.

Please advise on how to move forward. Thank you!

cc: @ibacher @mseaton @mksd

@nischith - OpenMRS core allows for modules to override the default authentication scheme with a custom authentication scheme by registering a spring bean of a specific class. Unfortunately, core does not account / allow for this to happen in more than one module - there is no way to specify what should happen if multiple modules do this. There is no explicit “sort order” and there is no ability to configure this.

The authentication module strives to work around this limitation by adding an authentication scheme implementation that delegates (DelegatingAuthenticationScheme) to another class that implements the AuthenticationScheme interface based on how this is configured at runtime (either explicitly in code or via configuration in the runtime properties file).

The oauth2login module (as far as I am aware) was built to always assume that, when installed, it is the authentication scheme that should be used.

In theory it should be possible to change the oauth2login module to depend upon the authentication module such that the oauth2login scheme is not registered as a spring bean but configured as the bean to delegate to from the authentication module’s DelegatingAuthenticationScheme, but I haven’t looked at other conflicts that might arise.

Another option is that we change core to allow for more than one module that provides authentication schemes to be installed simultaneously.

FWIW, I’d love for the authentication module to support oauth2 authentication natively, and merging these two efforts together. That would be another possible path.

For now, as things are designed, it is likely not possible to use these 2 modules together.


1 Like

@mseaton Thanks a lot for taking the time out to clarify things. So, it is clear that these two modules were developed independently and unless some fundamental changes are made, it will be difficult to make both of them work together.

That’s correct.

@mseaton and I once discussed this on Slack and I totally agree that this is the way to go.

@nischith also correct.

1 Like

In summary:

openmrs-module-oauth2login brings in the much needed SSO (Single Sign-On) capability but I think with just this module there is no way of tracking User log-in/ log-out timestamps and similar statistics (for these things there is a dependancy on openmrs-module-authentication)

To make the two modules compatible, I think almost all the changes need to be made to openmrs-module-oauth2login as explained here:

From here on, I don’t really know how the decision making happens at OpenMRS to make this a reality, but if it does happen, it would be wonderful for implementations!

If a plan does get chalked out, I would be happy to contribute.


It would be for the @Platform_Team to take this piece on their roadmap and start laying out specs and actionable tickets. From that point on dev work may be kick started (maybe by you?) and be reviewed by the Platform Team.

Best would be to discuss this over an upcoming TAC call - @grace?

1 Like