Possible to decouple authentication and authorization

#1

Hello all. I have a few questions about regarding user authentication/authorization. I have looked on the community site for an answer but didn’t see anything related to my question. I am fairly new to this particular technology stack so I apologize in advance if this seems fuzzy.

  1. My client has a current IAM solution that uses a COTS product for SAML and OAuth/OIDC authentication and high level authorization. The issue is that the product does not support the SMART framework. I’m wondering if there is a way to decouple the authentication and authorization so that the current IAM solution could do the authentication (most of our current Medicaid users are already in this user store for a different app) and then redirect to another authorization service for the authorization?

  2. If the answer is yes, you can decouple, would that mean that any potential 3rd party app would need to know that authentication can’t perform any SMART framework work?

  3. As a follow-on, I would also assume that the 3rd party app would contact the FHIR API for the capability statement which would end up sending the user to my IAM solution for authentication which would then have to send the user somewhere else for authorization and then finally back to the FHIR API.

#2

SMART does not say anything about authentication; it assumes that the authorization server does that in some fashion. Also, SMART does not say anything about the relationship between the Authorization Server and the Resource Server. Obviously, there has to be one, but it’s up to the implementer to decide how.

GIven that, I would expect that you can decouple no problems. It should be totally transparent to 3rd party apps though, since whatever happens for authentication is not part of the exchange. I think your assumption is not quite correct:

the 3rd party app would contact the FHIR API for the capability statement which would end up sending the user to my authorization service, which would send the user to my IAM solution for authentication which would then have to send the user back to my authorization service and then finally back to the FHIR API.

That’s how authorization works on test.fhir.org - facebook / google do the authentication. A write up about it here: http://www.healthintersections.com.au/?p=2108

#3

Hi Grahame. Thanks so much for the quick reply and turning on the light bulb. I do get caught up in the old “style” of IAM where it has to be very methodical; auth then az then move on. As you say, there is no reason why the authorization service couldn’t somehow determine that authentication hasn’t happened, redirect to make that happen and then do authorization. Thanks again. I’m sure I’ll have other questions as I wade through all this.