Double Layer OAuth

At the last connectathon, we had two servers offering OAuth based logins. They took two totally different approaches:

  • My server used OAuth to delegate authentication to public/commercial identity manager services such as Google or Facebook (and HL7 too). Once authorised, users had open access to the FHIR API
  • Josh Mandel’s server used OAuth to let the user choose what kind of operations the user could do on the FHIR API, but users were managed by the server

The way my server works is to ask the OAuth provider (Google or Facebook) to access the user’s identity. In order to give me that permission, the server has to identity the user (and I have to trust them to do that correctly). The problem with implementing like this is that while I identify the user, I’m not offering the user any choice as to what access their user agent (e.g. web site or mobile application) will have to the resources my server protect – which is their medical record (well, their prototype medical record anyway).

Josh’s server does that – it asks you what parts of your medical record you want to make visible to your user-agent, and whether you want to let it change any parts of it. So that’s much better (aside: There’s a number of reasons why you might want to limit access, but there’s also some real risks to that as well. These are well known problems I’m not taking up here). The problem with the approach Josh’s server takes is that you cannot delegate identity management, and managing user identity is hard and expensive.

So, can you have both? Well, it turns out that you can, but it’s pretty hard to visualise how that works. Josh explains how the process works here:

Josh made that video specifically to explain to me how the process works (thanks). So I’ve gone ahead and implemented this based on Josh’s explanation. You can check out how it works here: https://fhir.healthintersections.com.au/closed. In this example, the web server acts as a client to it’s own underlying RESTful API. Initially, you have to login:

oauth_login

Once you choose to login using OAuth, you get this page:

oauth_id_page

 

You can identify yourself using 3 different external providers, or you can login using a username/password (contact me directly to get an account). Or, if you know me via Skype you can authenticate to me out-of-band using the token. Once you’ve identified yourself, then you get asked what permissions to give your user-agent:

oauth-choice

For now, this is just a place holder while we decide (argue) about what kind of permissions would be appropriate. The only right that is currently meaningful is whether to share your user details (internal id – which might be a facebook or google internal id, user name, and email address). If you share them, the user agent can use them; if you don’t the user agent won’t be able to recognise you as the same user again.

I wrote this to demonstrate the process, since it’s not easy to visualise it. Developers who want to use this can consult my API documentation (it’s as close to Google as I can get; there’s no JWT token, but I will be implementing IHE IUA later). For developer’s who want to try this out locally, there’s a predefined client you can use:

client_id = LocalTest
client_secret = SecretForLocalTest
name = Local Test Client
redirect = http://localhost:8000/app/index.html

Contact me if you the redirect doesn’t suit, and I can add it to the list, or set up a different client for you.

Btw, in case anyone wants to see the source – this is all open source.

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen

*

%d bloggers like this: