OAuth 2 Login module installation error

The system config is OpenMRS core 2.6.0 / Refapp 2.13.0-SNAPSHOT / Ubuntu 22.04.1 LTS

The effort has been to install oauth2login on a system with the above mentioned specifications. The below error (500–Internal Server Error) is seen after the installation of the module: org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from class path resource [webModuleApplicationContext.xml]; nested exception is java.io.FileNotFoundException: class path resource [webModuleApplicationContext.xml] cannot be opened because it does not exist

The complete error log is here

Please suggest the right solution to fix this error.

Thank you.

I don’t think we’ve ever tried it yet with Core 2.6.x. Not that the error message that you shared necessarily hints at this, but it would be worthwhile trying the setup with a released Ref App (say 2.12.0) and a released version of the module (say 1.1.0).

@mksd

I just tried your suggestion. Even with Ref App (2.12.0) and OAuth 2 Login (1.1.0), I continue to get the same error mentioned before.

Any further help will be really appreciated.

Thanks a lot!

@mksd

Please let me know if I need to try a different version of Core. What would be the latest stable versions of Core and Ref App that would work well with OAuth 2 Login (1.1.0)?

Thank you.

OAuth 2 Login really requires the oauth2.properties file to be there btw, and configured with URIs pointing to the various needed endpoints of the IdP.

Did you go through the README and set everything up accordingly? There are whole guides for Keycloak and Google API. The latter can be convenient to test things out.

Yes, I have very carefully gone through the README and the instructions for Google API

The oauth2.properties file also has been placed correctly at the below location:

/var/lib/OpenMRS

Thanks!

@nischith / @mksd - unless things have changed in the last year (and from github it does not appear that they have), in my experience this module is not yet compatible beyond OpenMRS 2.3.x, due to upgrades to the Spring Framework in core and the dependence that this module has on specific versions of Spring due to the utilization of Spring Security.

@mseaton

Right now I am in the middle of an ongoing implementation. I really think this module adds a lot of value and makes the login process efficient. Would you advise downgrading to OpenMRS Core 2.3.x to incorporate this module? or are there any suitable alternatives?

Also, it would be good to know if there are implementations out there making good use of this module.

Thanks!

@mseaton we use it successfully in Ozone Pro with Ref App 3.x, which brings Core 2.5.8.

This is why I was suggesting to go down one notch.

1 Like

Yes, this module is solid and is used in production to bring OAuth2 enterprise integration, but not yet against Core 2.6.x.

That’s great! I’m glad it’s working. I must have run into other unrelated issues.

Also as soon as we have released Ref App 3.x we will want to bump Core to the latest snapshot. At that point we will face and fix the issues that arise against Core 2.6.x since they will show up on the bleeding edge Ozone Pro.

1 Like

Now, I have changed the whole system configuration as suggested to suit the OAuth 2 Login module.

Right now the system specs are like below:

Core 2.5.8

Ref App 2.12.0

OAuth 2 Login 1.1.0

The earlier error has been solved and the Google sign in page is displayed initially, the sign-in also happens successfully through the Google APIs.

But after all this, back at the redirect URL the below error is seen:

Request processing failed; nested exception is error=“access_denied”, error_description=“Error requesting access token.”

The complete error log is here

I really hope this gets sorted out.

Thank you!

The stack trace points to this line at the moment when fetching the user info JSON from Google API. And basically this request gets denied.

Difficult to say without following how all this was configured, unfortunately it is also possible that things changed on Google’s end since that guide was first written (mid 2019).

@mksd The issue has been solved!

As you rightly pointed out, it looks like that now, an additional step is needed at Google’s end that was probably not required earlier.

The additional step that is needed is:

App verification (this needs to happen before configuring the consent screen)

Basically, only verified Domains/ Apps are allowed to access the services and all other additional details are clearly mentioned in the new setup pages.

Thanks a lot for all the inputs!

Thanks a lot for building this module!

1 Like