RE: OAuth 2 Login Module

Hi Dimitri,

I saw this discussion about the OAuth2 module being separated from the OAuth2 Login module that you seem to be working on. The Daniel Kayiwa pointed me to the new Git Repo where you have now actually placed Oauth2 Login.

[context chat]

Can you please fill me in on some questions that my colleagues and I have been westling with:

  1. Is OAuth2 Login going to be replacement for the old module which can be used with FHIR2 to implement the SMART on FHIR app authorisation paradigm? And are you using it for that purpose? Or if not, what kinds of authorisation scenarios are you trying to support.
  2. Is the instruction page on the Wiki for OAuth2 [OpenMRS - OAuth2 Module - Projects - OpenMRS Wiki] now completely out of date, and irrelevant to your new implementation? If so, have you got documentation for how to use OAuth2 Login? My searches for this topic on the Wiki do not find any pages.
  3. Do you know if a compiled OMOD for OAuth2 Login will work in the latest Reference Platform installation (2.11) that we have downloaded and are now configuring? Or will it only work with future OpenMRS versions? We tried following the instructions to add updated XML for URL redirection, and the compilation fails due to version conflicts. I assume a similar XML config/ java compile/ maven build will be needed make an OMOD that suits our installation as well??

Thanks in advance, Keith

Hi @keithduddy,

We are not implementing SMART on FHIR, however it looks like that you would need something like the OAuth 2 Login module if you were to implement SMART on FHIR (I’m saying this with my limited knowledge and understanding of it.)


The OAuth 2 Login module is documented through its README: GitHub - openmrs/openmrs-module-oauth2login: Delegates user authentication to an OAuth 2.0 authentication provider.

Did you go through it? If yes, let me know what areas of it are unclear or incomplete.

OAuth 2 Login requires

Ref App 2.11.0 bundles:

Looks like all is good there :+1:

OAuth 2 Login requires to configure an file, and possibly a pair of OpenMRS global properties when used with the Ref App, but no XML file that I’m aware of.

Thanks very much for your prompt response @mksd - it looks like it’s not quite what we are after. Our SMART on FHIR structure would use the built in authentication in OpenMRS to get a token and then make FHIR REST calls in a session set up with that token. I think that’s what the old OAuth2 module did, but you’re clearly just making a gateway to a 3rd party authenticator.

In future I’ll make sure I read documentation at GitHub as well as looking in the Wiki!

cheers, …|<

I know it feels like the longer path, but why don’t you couple OpenMRS with an IDP and implement SMART on FHIR by getting the tokens from the IDP?

Any serious entreprise deployment of OpenMRS should IMO be done with an IDP and without relying on OpenMRS’ basic auth mechanism. Think of HIS setups that require SSO for instance.

SMART on FHIR is built on OAuth2, but in a slightly different way than the OAuth2 module.

To try to spell things out about, in OAuth2 terms, there are 3 participants: a client (the application trying to request access to a resource, possibly on behalf of a user), the authentication provider (which determines whether a request is provided) and a resource server (which has the data of interest).

The OAuth2 module effectively turns OMRS into an OAuth2 client that allows OMRS to login using a third-party authorization server, but there’s no direct relationship between the authorization server and the resource server (the OMRS API).

SMART on FHIR requires some adjustments to the authorization server to properly implement the SMART App Launch protocol and some components necessary to the SMART App Launch (generally a patient selector and possibly an encounter selector). In the SMART on FHIR flow, we end up needing to treat OMRS as a resource server rather than an OAuth2 client.

How we get the two uses of OAuth2 (external identity provider and the SMART flow’s additional properties) to work together is… an as yet unsolved problem.

1 Like

Thanks to you both for your valuable feedback. We will probably just do some unauthenticated REST and/or FHIR queries from our platform to a sandboxed OpenMRS that is not available on the open internet. We are really just trying to demonstrate the use of FHIR for an arbitrary integration with an EMR… and SMART on FHIR is not essential, just access to FHIR profiled resources.

If we deploy OpenMRS for a customer, I agree that there’s probably going to be another authentication server that provides SSO within an organisation, and we’ll delegate authentication to it in the way you suggest with IDP.



Keith Duddy, Senior Advisor

S23M Collaboration for Life AU: +61 403 002 097 NZ: +64 22 459 9395

This e-mail message and any attachments contain information that is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, pass on or copy this message or any attachments. If you have received this email in error, please notify us by return e-mail and erase all copies of this message including any attachments. Thank you.

A post was split to a new topic: FHIR2 and basic authentication