This topic is spun off a side discussion on Fitbit Web API integration topic.
Please continue the discussion here. I think it is important to have.
I just want to note a couple reservations I have concerning implementing OAuth that authorize through outside auth servers. I fully expect push back but, okay.
- I consider them to be insecure and are more of a matter of convenience.
- Relying on outside authorization servers availability can prove problematic in offline scenarios. Iām sure weād have fallbacks but still, why offer?
I also very much disagree with running any EHR in hosted services. I know itās a rage and the next great convenience but, this notion is very much pushed by hosting services with vested interest in normalizing this environment. Doing so exposes patient data to outside players(nefarious or not) regardless of their guarantees. The best security is the less data exposure, the better.
Anyway, remembering we now have APIās that vendors will create client applications using, we need to provide provider control over their access levels/scope. Not to forget some review control for what data is being introduced to patient chart. This all needs to be taken into account for any authentication scheme implemented.
This to me suggest we implement our own authorization server to authenticate against. Though this may seem overkill I believe, for institutional settings, very much needed.
Nothing against OAuth whether a two or three legged implementation. Itās where the authentication authorizations originate that give me pause.
Okay, thatās my take. Let me have it! 
@Piyush_Jha
There is already some infrasture for PACS and maybe you could also spare some time to use your experience with Authorization/Authentication to help get us started.
1 Like
If youāre talking about OAuth stuff such as stuff like āSign into Googleā and stuff, I am also in the mindset that we shouldnāt be using them as APIās get compromised and things break so using them in a medical setting sounds ridiculous. However I do see them being useful for stuff like the patient portal which most of the time is online.
Enforcing a single auth service will be a good start. Be it logon, portal, fhir or a device connection, all should supply access token(s) and role they are asking and receive a session token.
1 Like
Yes true. Your thoughts on having our own authorization server to authenticate against?
Always good to leverage other projects whose primary focus is the service this project needs. That frees up developers and administrators to almost exclusively focus on āMā of the emr. There seem to be few drop-in php servers that do this. That will complicate setup and updates a bit.
Until recently that would have been the first choice. But after becoming increasingly reliant on dockerized components, we are conflicted. Dockers are operating environment equivalents to emr modules. Going that way relaxes the php constraint and you have more options. Now you could choose a node server without requiring elaborate install instructions.
Of course as long as a modular approach - something like what HybridAuth calls adapters - is used, you could include internal php oauth2 server as standard but allow for external oAuth2 server or active directory server needed by matrix.
Imo, anything we do along these lines needs to be kept as closely within openemrs domain as possible.
Unfortunate or not, PHP is our language and while spinning up docker resources to parlay with is fine if it is run in a local environment i.e. offline availability.
I am extremely conflicted, (and have been from the beginning of our focus towards docker), with relying on access and/or running in internet. Both for housing data within that environment or dependency requirements. We simply canāt be/support everything for everybody! Weāre almost to the point we would need to chose one, and be good at that.
I keep thinking about institutional and clinical settings with whatever we do along the lines of application access, will be tolerated by both. Including offline for both institutional and disaster settings.
So, serving authorization as our own provider is necessary imo. Starting and running a node server is very doable and can be done dynamically or better still, via our APIās. Itās been awhile since iāve looked at what is out there to support, so I probably should take a peek but, I was hoping somebody would pick up this task. Then we could take it from thereā¦
Always appreciate you input, thanks.
If you want to get an idea, look at GitHub - thephpleague/oauth2-server: A spec compliant, secure by default PHP OAuth 2.0 Server. You could even have embedded server interface with other auth servers but each of these make setup and troubleshooting increasingly complex. Reference to node.js auth server was figurative. Regardless of where the auth servers run, they should be black boxes.
As in the earlier post, by all means basic authentication needs to be included. But as with matrixās active directory auth, there is need for other sources. Even in small offices it is already a pain to sync workstation accounts, email accounts and emr user accounts. That causes users to write passwords on post-its inside the drawers. How secure is that access?
It all goes back to deconstructing existing code one script at a time. But that is not so cool 
Aww Gesh, I just donāt have the energy or typing skills to get into that debate.
yep, looked into a couple years ago. It has some potential. Bottom line for me, iām somewhat content with assigning app tokens and secrets for the APIās. Itās user interface to support that needs to be done. At least, to move forward a smidge.
1 Like
Thank you for moving this to a different topic. Something that needs to be worked on is the authentication of OpenEMR and I was planning to looking into getting Firebase Authentication API integrated since the MFA setup has a limitation of no way to recover if you lose the device used for it.
1 Like
Iām assuming youāre running an App interfacing to our APIās or logging on for some purpose.
Would not Firebase be more for authenticating your app logon than openemr login?
I have been trying to replicate your integration from the previous post (GitHub branch), but I keep running into 500 errors. I had to clone the specific commit as well, since the latest version of the branch still gives the 500 error. Is this setup still running on your end?
We havenāt upgraded to current version. Will take a look in next couple of days.
Looks like this was a proposed solution but was never integrated into openemr. I donāt remember seeing this last year.
@mdsupport , was this reviewed by anybody. What was the outcome when you purposed. Whatever the case, from my quick once over, I think it could be integrated and still address some of my concerns.
Iād need to look closer but nicely doneā¦
I actually tried to clone that branch and run it, but I think the 500 error was due to not importing the HybridAuth plugin, which Iām working on it right now.
Chances are the 500 was a result of a PHP error. Error log should tellā¦
Agree would be nice to refactor this into most recent codebase: src/Common/Auth/AuthUtils.php
Sorry, we did not include instructions from the code into the forum post. The commit is merely the integration layer between emr and hybridauth.
- Update composer to require latest release of hybridauth. (missed that in commit)
- Review list of hybridauth adapters. Since your goal is Firebase, I will assume Google will be the only adapter with specific protocol applicable to Firebase (if any) as per their documentation note:
Some providers such as Google and Yahoo may use multiple protocols for their APIs and as naming convention we append the protocolās name to the adapterās
-
Follow instructions starting with Google steps that generate authentication related objects.
-
Rename template yaml file in config directory and replace/add items from prior step.
-
Hybridauth allows default callback urls as well as adapter specific callbacks. Regardless of your choice or adapter specific behaviour, after successful authentication Google needs to invoke login/hauth_check.php.
-
For successful passthru, we lookup either users.email or users.direct_email to locate one (and only one) emr user. Multiple hits are treated as no hits.
-
At the end, you should see login screen display small icon for each enabled adapter.
-
By clicking on āGā icon, you will use your current Google session (and related email address) as emr login. Each auth provider controls various aspects of this process. For example, if you currently have no active session Google will offer login screen followed by prompt on your phone or whatever additional MFA you have set for your google account.
There is provision in the code for patients email as well to enable patient portal integration. But that branch does not take it further.
1 Like
Okay, sorry I did see this soooo, the present is a new day to see if we canāt get this implemented/integrated. I suppose I could go ahead and do the integration if @mdsupport you donāt want to do the PR and/or you want to authorize me to use your work. Iād hate to see this opportunity pass by again!
@cyril How are you coming with your project?