HSWT

OAuth 2.0

I've looked at all of the diagrams and this doesn't seem to be a straight forward concept for me. From my understanding the basic concept is that where you get the data from and where you get the permission from are two different sources. Like, your dad actually gives you the keys to the car, but he has to make sure you have your mom's permission first.

Hay on Fhir has lots of good posts (although I've read only a small minority). Here's the one they did about Oath2. I've been looking through this stuff for a few hours, and I think part of it is the terminology.

I like Hay's explanation. You're on your web browser (or, say, phone), and launch an app (this may be called a launch url). The app thus sends you/your browser/your phone to a login page. The login page is on an Authorization server. You enter your login information, and also say how much of your data you want to allow the app to access (I think that is the most confusing part). YOU are telling the APP what information it can have access to WHEN you're logging into the Authorization server. The Authorization server then redirects you (via a redirect url) back to an endpoint on the App, with a message that contains an "authentication code" which gives users permission to access their data. The app then effectively exchanges this authentication code (plus some other data) to the same Authorization Server for an Access Token. The app then asks for data from the FHIR server, and includes the Access Token. The FHIR server confirms the token is legitimate, then sends the data back to the app. The app then uses the data to make a webpage and sends it back to you.

It's taken me at least six times through this to make any sense of it. And again, it's the terminology that's confusing. For instance, in the official OAuth2 description, it doesn't make clear why the Resource owner would be asking the client to get it's own data for itself. There are also a couple of different flows of information that make this confusing again. Lastly, I think most of the diagrams around FHIR are originating from the EHR, instead of a standalone client.

I'm going to try it with some names. The Resource Owner is Grey. Grey's User-Agent is his Chrome web browser. His Client, Gimme, is a Smart-on-FHIR app. There's an Authorization server called FHIRAuth, and a Resource Server called FHIRData.

Grey opens Chrome, and goes to http://launchgimme.com. This is the launch URI for his Gimme App. It sends Chrome to FHIRAuth, and includes the Gimme app identifier, requested scope, and another URI, http://gimme.com. Grey gives his username and password to FHIRAuth to prove he is who he says he is. FHIRAuth also asks Grey if Gimme can have access to FHIRData, Grey agrees (this is detailed in the scope, which says specifically what data Gimme wants access to and what kind of interaction it wants with it - read, write, etc). FHIRAuth sends Chrome to http://gimme.com (the redirect URI), along with an authorization code. Gimme then takes the authorization code and sends it back to FHIRAuth, along with the redirect URI for verification. FHIRAuth authenticates Gimme, validates the authorization code, and ensures the redirect URI is the same as the one used in the previous step. FHIRAuth then sends Gimme an access token. Gimme can then send the access token to FHIRdata, who sends back the data requested. Gimme then takes the data and does something special to it (otherwise, Grey would just get the data himself), and displays it prettily in a website, that gets sent to Chrome, and Grey looks at it in awe.

That's my best description after staring at all of it for the afternoon. Anymore insights, I'll try and update this. Likewise, please feel free to tell me how I got it all wrong!