FHIR Chat · Keycloak for SMART authz · smart

Stream: smart

Topic: Keycloak for SMART authz

---

Josh Mandel (Oct 22 2020 at 21:38):

BTW @Lee Surprenant, following discussion over here: I'd love to get an overview of how you're using KeyCloak to implement a SMART authz server -- I think there's probably broad community interest in this point. Any chance you'd be up for a chat? (And if you're amenable, we could record / share for folks who want to catch up later.)

Jim Steel (Oct 22 2020 at 23:26):

@Michael Lawley and @Dion McMurtrie and I would probably be interested in this. We're using Keycloak for some SMART stuff too.

Sagar Shah (Oct 23 2020 at 12:14):

I am too interested on this. We have OAuth Server (built using spring security) on cloud and EHR as on-prem solution. and we are planning to migrate over to KeyCloak for building OIDC and extending for SMART on FHIR from existing OAuth Server

Lee Surprenant (Oct 23 2020 at 14:06):

Thanks @Josh Mandel, I'm happy to join a call and share where we're at with Keycloak on this effort. I'm especially interested to hear from others using Keycloak (or RedHat SSO) for SMART-on-FHIR support.

Lee Surprenant (Oct 23 2020 at 14:07):

Does anyone know any of the folks involved with "igia" (https://igia.github.io/docs/igia-keycloak~introduction)?

Lee Surprenant (Oct 23 2020 at 14:18):

I noticed some in the DaVinci community are using Keycloak as well. @Yunwei Wang @Andy Gregorowicz I noticed you both have edited the keycloak section of the DaVinci CRD README...is this a subject you'd be interested in discussing?

Josh Mandel (Oct 23 2020 at 14:42):

Super, @Lee Surprenant! Let's see who else chimes in here as interested, and then try to schedule a time for a conversation late next week, if that works?

Lee Surprenant (Oct 23 2020 at 14:43):

works for me

Sagar Shah (Oct 30 2020 at 12:02):

Just curious, if there was any conversation around this week on this topic?

Josh Mandel (Oct 30 2020 at 16:20):

We didn't schedule one -- but let's do so for next week. @Lee Surprenant are there times next Friday 11/6 that would work for you?

Lee Surprenant (Oct 30 2020 at 17:10):

I'm free most of the day. Pretty much anything outside of 10-11 ET

Josh Mandel (Oct 30 2020 at 18:02):

Great -- I just sent an invite for 2:30p ET. Anyone else who wants to (to lee, Sagar, Jim, Michael, Dion -- recognizing that the time will be really poor for some; we'll record it!)

Josh Mandel (Oct 30 2020 at 18:03):

(Others please let me know if you want to be added to the invite)

Venkateswara R Davuluri (Oct 30 2020 at 18:04):

Hi Josh, please send the invite to me also. (dr.davuluri@gmail.com)

Josh Mandel (Nov 03 2020 at 16:15):

(Note that we moved this later in the day, to 4p ET, to accommodate Australia slightly less terribly. Everyone on the invite should have seen an update.)

Sagar Shah (Nov 03 2020 at 16:46):

I may be tentative around that time. But I am hoping this will be recorded and I can go though it later.

Josh Mandel (Nov 03 2020 at 17:04):

Thanks -- we'll plan to record it (and for folks on the call: please remind me of this plan so I actually hit the button!)

Brian Postlethwaite (Nov 03 2020 at 20:51):

Can you please add me to the invite too? Thanks

Josh Mandel (Nov 03 2020 at 20:55):

Done!

Ian Bacher (Nov 04 2020 at 13:09):

I'd also be interested in this discussion if it's possible to include me (ian_bacher@brown.edu). Thanks!

Josh Mandel (Nov 04 2020 at 22:55):

Done!

Lee Surprenant (Nov 06 2020 at 13:11):

FYI I just posted a quick advert on the Keycloak Zulip instance (yes, they use Zulip too!)

Lee Surprenant (Nov 06 2020 at 13:11):

https://keycloak.zulipchat.com/#narrow/stream/211273-user/topic/SMART.20App.20Launch

Josh Mandel (Nov 06 2020 at 20:52):

Meeting in 8min: Teams link

Dion McMurtrie (Nov 06 2020 at 22:26):

Thanks for the meeting @Josh Mandel and particular thanks to @Lee Surprenant for sharing.

As well as our efforts I'm aware of this https://github.com/itcr-uni-luebeck/ontoserver-keycloak so I think it would be great to provide a space for those who've done Keycloak + FHIR to share knowledge/approaches so we don't have to keep independently learning the same stuff. Mostly it is a journey of figuring out how to configure Keycloak to do what you want it to do, which is a bit of a learning curve.

Josh Mandel (Nov 06 2020 at 22:34):

Thanks all for joining the discussion today! I've just uploaded the recording to https://youtu.be/Pp32GOOq0Vw (YouTube may take a few minutes to finish processing.)

Thanks especially to @Lee Surprenant for sharing the work you've done.

Sagar Shah (Nov 06 2020 at 22:44):

Thank you for setting this up and providing very useful information. I also wanted bring up similar point, but could not bring it due to time constraint that Okta is working on similar initiative too by using AWS lambda as a SMART proxy that adds SMART on FHIR capabilities on top of its OIDC solution. That SMART proxy runs outside of the Auth Server solution of Okta, which is very similar to what @Lee Surprenant showed in his diagram. Thanks @Josh Mandel for setting this up and sharing the recording

Josh Mandel (Nov 06 2020 at 23:04):

Thanks @Sagar Shah -- are their docs or any background reading on this approach with Okta?

Sagar Shah (Nov 06 2020 at 23:08):

@Josh Mandel I believe, there are some contractual obligations because of which I may not be able to share it at this point. But I can point to these 2 open source git hub repositories, that may provider some pointers https://github.com/dancinnamon-okta/okta-smartfhir-demo and https://github.com/dancinnamon-okta/SoF-Demo. Hope this is useful!

Paul Church (Nov 07 2020 at 04:17):

Thanks for the recording, I couldn't make the meeting time but that was very interesting.

Jens Villadsen (Nov 07 2020 at 12:47):

FYI - I have a setup where we bridge SAML to OAuth in Keycloak ending up with a 'SMART'-like behaviour (https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/7045392/Security) where the JWT more or less follows SMART - should it have any interest.

Dan Cinnamon (Nov 12 2020 at 05:11):

@Sagar Shah @Josh Mandel @Lee Surprenant ,
Shoot! I'm totally late to the party :). Saw the video from last week, and yes it does certainly look familiar to some of the research I've been doing- in my particular case using Okta as the authorization server- Lee sounds like you and I ran into a number of the very same issues and overcame some of the same hurdles. I'll also be checking what i'm doing with the "aud" input parameter, as I think I'm currently working in the same way you are.

Lee Surprenant (Nov 16 2020 at 19:36):

@Josh Mandel one thing we ran out of time to discuss in that call is the issue I hit where keycloak is expecting the client_id in the refresh token for public clients (whereas SMART says its not needed).
Given that Keycloak is a certified OIDC provider, and that it shouldn't be burdensome for clients to include the client_id in the exchange (since they already use it elsewhere), would you be opposed to adding it into the corresponding exchange for SMART App Launch? Should I open a JIRA ticket for it?

Łukasz Dywicki (Nov 24 2020 at 23:03):

Lee Surprenant said:

Josh Mandel one thing we ran out of time to discuss in that call is the issue I hit where keycloak is expecting the client_id in the refresh token for public clients (whereas SMART says its not needed).

Not sure if that's issue after all. Refresh token is something given to client and expected to be returned by it. I am not quite sure if client should bother at all about what refresh token is, just bring it back to obtain new tokens.

Lee Surprenant (Nov 30 2020 at 12:32):

My apologies for the sloppy language. What I meant above is this:

keycloak is expecting the client_id in the request to refresh the access token for public clients (whereas SMART says its not needed)

Yogesh Dhimate (Nov 30 2020 at 18:07):

Josh Mandel said:

Thanks all for joining the discussion today! I've just uploaded the recording to https://youtu.be/Pp32GOOq0Vw (YouTube may take a few minutes to finish processing.)

Thanks especially to Lee Surprenant for sharing the work you've done.

Thanks a lot for recording and sharing this. Is there a plugin/extension required to support wildcard scopes in Keycloak?
How does Keycloak know patient/*.read means patient/Observation.read AND patient/Immunization.read (etc...)

Lee Surprenant (Nov 30 2020 at 19:01):

Hi @Yogesh Dhimate what we spent most of the time discussing is how to get the right context and scopes associated with the access token. What we did not cover is how to actually enforce access controls based on the combination of the user context and the approved scopes. It sounds like you are asking about the latter.

Michele Mottini (Nov 30 2020 at 19:06):

How does Keycloak know patient/*.read means patient/Observation.read AND patient/Immunization.read

The authorization server does not really need to know that, doesn't it? Is the resource server that has to check that - 'I am getting a request for Patient, let me check if that's admissible based on the access token scopes: look for patient/Patient.read or patient/*.read etc.'

Yogesh Dhimate (Nov 30 2020 at 23:10):

Thanks for your reply @Lee Surprenant Yes I was talking about the latter part of enforcing the access controls.

Hi @Michele Mottini - thanks for your input. That was my point, that if the resource server is getting a request for patient/Immunization.read, but the scope being presented is patient/*.read, should it be the responsibility of the resource server to interpret the wildcard and allow/deny the request.

In my architecture we have an API gateway layer on top of the resource server. The API gateway layer protects the APIs by applying security policies like OpenID token enforcement etc.

Outside of SMART on FHIR, we haven't encountered the wildcard scopes, so the policy enforcement for scopes is verbatim. The list of scopes can be configured for each API or a resource endpoint when applying a policy.

e.g. API security policy for /Immunization resource can be configured with scopes like openid fhirUser patient/Immunization.read
With this configuration when a SMART app tries to access the resource, it must present a token which proves that it has been granted access to these scopes.

Since this validation/comparison of scopes at API policy level doesn't take into account wildcards, an app with these scopes openid fhirUser patient/*.read can't get past the security policy layer as the patient/*.read doesn't translate to patient/Immunization.read.

I was wondering whether authorization server should interpret the wildcard scopes and translate/return the appropriate scopes accordingly.

Michele Mottini (Nov 30 2020 at 23:14):

Note that you can forbid wildcard scopes, and require apps to use always explicit ones (some existing server do that - eg Cerner)

Yogesh Dhimate (Dec 01 2020 at 02:08):

Thanks for your response. I didn't know that we can forbid specific scopes. If we were to forbid these scopes, how Is this information communicated to the client apps? Do we document in API documentation or it should be in the CapabilityStatement?

Michele Mottini (Dec 01 2020 at 04:21):

Typically as part of the app registration there is a list of allowed scopes, or in some cases the app has to select which scopes it wants from a list of all the available ones.

Michele Mottini (Dec 01 2020 at 04:23):

Here is an example from Cerner app registration:
image.png

Jenni Syed (Dec 01 2020 at 15:00):

You can also advertise what scopes you support in the conformance doc for SMART

Jenni Syed (Dec 01 2020 at 15:01):

http://www.hl7.org/fhir/smart-app-launch/conformance/index.html

Yogesh Dhimate (Dec 04 2020 at 15:30):

Perfect thank you.

Ryan Harrison (Dec 11 2020 at 08:47):

@Lee Surprenant @Gino Canessa @Brian Postlethwaite @Ian Bacher @Dion McMurtrie
Thanks so much for the informative talk!
Y'all mentioned working on a cookbook for SMART on FHIR in Keycloak (~59 min). Did anything ever come of that effort?

Ryan Harrison (Dec 11 2020 at 08:49):

@Sagar Shah Would you consider presenting a similar talk on the Okta + API Gateway + Lambda's approach from https://github.com/dancinnamon-okta/okta-smartfhir-demo ?

Sagar Shah (Dec 11 2020 at 12:30):

@Ryan Harrison - Wish, I could. I am not in a position to present a talk as we have not explored it except for understanding high level flow and we are not planning to use it, as we are not going with Okta solution for OIDC. We just came across that as an option while exploring. I will try to put down the high level steps here soon here

Ryan Harrison (Dec 11 2020 at 14:45):

@Sagar Shah Thanks for the prompt response/clarification, and for bringing the Okta community configuration to the communities attention.

Lee Surprenant (Dec 11 2020 at 15:58):

@Ryan Harrison Nothing from me on that front yet. Still want to get to it though. The latest news is @Ian Bacher 's pull request got merged which will change things a bit (no more need for a token-response-rewriter)

Sagar Shah (Dec 11 2020 at 16:01):

@Ian Bacher /@Lee Surprenant - Is that available in 11.0.3 v of keycloak? or going to be part of next release?

Ian Bacher (Dec 11 2020 at 16:15):

@Sagar Shah The Jira ticket indicates it will be included in the 12.0.0 release. Note that the changes are (to the best of my knowledge) not exposed through the Keycloak UI.

I'm still on board with helping get together a cookbook for SMART on FHIR in Keycloak, but probably in the new year.

Sagar Shah (Dec 11 2020 at 16:16):

That will be a great help, @Ian Bacher . Excited to see new release of keycloak of 12.0.0

Sagar Shah (Dec 11 2020 at 16:22):

Here are the steps in general @Ryan Harrison . Hope this helps!
End-to-End Flow

---

1. User accesses a SMART-enabled app.
2. App determines authz endpoints from metadata.
3. App opens the /authorize proxy endpoint. (Note this is the proxy endpoint and not real auth server endpoint)
4. Authorize proxy caches original request and performs authz with patient picker app instead.
5. User logs in with Auth Server.
6. User is shown the patient picker app.
7. Patient, and downscoped scopes are combined with original request details and sent to Auth Server in a new /authorize request.
8. Auth server calls a token hook to validate that the request actually came from the patient picker, and to insert the selected patient into the token.
9. Auth Server returns authorization code to the authorize proxy. The authorize proxy redirects the browser to the OAuth2 callback url of the app.
10. App calls the /token proxy to obtain an access token.
11. /token proxy obtains the token from Auth Server, uses a private key to perform client authentication
12. /token proxy puts the proper launch response alongside the access token from Auth Server.
13. App accesses the FHIR API

Ryan Harrison (Dec 11 2020 at 22:03):

@Sagar Shah Well that sequence list is the first step of the playbook. Then come the Keycloak (or Igia on Keycloak?) specific instructions for each step. Ideally backed by a repo with some automation (e.g. creating all the resource scopes and tedious configuration). Thank you!

Dan Cinnamon (Dec 15 2020 at 15:43):

Hi @Ryan Harrison - I'm the author of the Okta reference implementation- I'd be happy to do a presentation on it if people are interested. I've made some updates to it in the past few weeks:
1- I've provided some far more detailed documentation on it, contained here: https://github.com/dancinnamon-okta/okta-smartfhir-docs
2- I just did a major refactor of the components earlier this week to separate out the Lambda specific pieces of it so if there's interest in releasing in another serverless technology (Azure functions, GCP functions, etc) that should be quick to do. It leverages the serverless deployment framework so adjusting to other clouds should be seamless.

Josh Mandel (Dec 15 2020 at 15:47):

I'd be super interested in a presentation about this, Dan!

Dan Cinnamon (Dec 16 2020 at 22:44):

Great- perhaps we can shoot for a date later in January after connectathon. Whatever works.

Dan Cinnamon (Feb 04 2021 at 14:35):

Good morning everyone- well it was a crazy January- not sure where the time went. Is there still interest in covering the reference implementation I've done with SMART+Okta? If so, I thought I'd propose some time during the week of 2/15 to have that session. Thoughts?

Venu Gopal (Feb 04 2021 at 14:46):

Hi Dan, I am a new comer to this chat, and I am implementing a solution for India. I'm interested, if you have time

Sagar Shah (Feb 04 2021 at 15:29):

Thanks @Dan Cinnamon for checking. We have similar interests too in knowing what that SMART on FHIR proxy component works with AWS lambda works and Okta as an authz server (or any other auth server).

Ryan Harrison (Feb 06 2021 at 06:35):

@Dan Cinnamon Thanks for publishing your reference implementation! I would _enthusiastically_ attend a presentation the week of 2/15. Just say when (please @ me so I see it). https://meet.jit.si is my goto for small to mid-sized meetings. Please record if you're comfortable [^1].

cc @Elijah
[^1] The session Josh Mandel et al. recorded was fantastic: https://chat.fhir.org/#narrow/stream/179170-smart/topic/Keycloak.20for.20SMART.20authz/near/215912381

Josh Mandel (Feb 06 2021 at 22:34):

Yeah @Dan Cinnamon I'd be eager to join. Do you want to set up a time (or I'm happy to help!)

Dan Cinnamon (Feb 08 2021 at 14:06):

Awesome- thanks everyone! @Ryan Harrison @Josh Mandel @Sagar Shah @Venu Gopal - Right now Thursday the 18th looks wide open. In efforts to select a time that's somewhat reasonable for our partners in India, I was thinking we could do 9am CST- does that time work? In terms of jitsi- I'd be glad to use that platform- however, would like to post a link here beforehand. What's the best way to do that? I was thinking i'd just generate a GUID and use that as my meeting ID.

Josh Mandel (Feb 08 2021 at 14:39):

That works for me! Re: jitsi I'd note that the built-in recording capabilities are limited, so we might want to see if someone can record from their desktop as a backup.

Ryan Harrison (Feb 08 2021 at 18:25):

yes Yes! :)

That time works for me (18 Feb @ 9 am CT).
You can use any arbitrary room name you'd like.
And a recording backup is a great idea.

Sagar Shah (Feb 08 2021 at 19:54):

Works for me too. Thanks for checking @Dan Cinnamon !

Dan Cinnamon (Feb 09 2021 at 14:37):

Great! 9am central time on 2/18 it is then. We'll use https://meet.jit.si/smart-reference-review-with-dan for it. I've also attached a .ics file for your calendar if you'd like. invite.ics
@Ryan Harrison @Sagar Shah @Venu Gopal @Josh Mandel ^^

Rob Resendez (Feb 10 2021 at 05:24):

Hi! Lurker here super interested in oauth, oidc, smart auth and fhir. Implemented the fhir resource server and authorization server used in production by my company (an ehr vendor). We've been looking at replacing our authorization infrastructure w/ something new (keycloak, gluu, okta, identityserver)

I'd really love the opportunity to tune in for the presentation... would that be okay?

Josh Mandel (Feb 10 2021 at 14:20):

(I will answer for Dan because I happen to be reading this first.) Of course! that's why it's advertised here openly, to extend the invitation to everyone who is interested :-)

Ryan Harrison (Feb 12 2021 at 07:19):

@Angus McAllister Just in case you didn't notice this thread.
https://chat.fhir.org/#narrow/stream/179170-smart/topic/Keycloak.20for.20SMART.20authz/near/225698418

Josh Mandel (Feb 18 2021 at 00:06):

Aw, I'm going to have to miss tomorrow morning's session (conflict that I can't move) but will look forward to watching a recording if someone can make one. (My regrets, @Dan Cinnamon !)

Dan Cinnamon (Feb 18 2021 at 00:29):

Shoot sorry to hear that but will definitely get a recording going!

Gino Canessa (Feb 18 2021 at 18:29):

Thanks again @Dan Cinnamon for the presentation this morning (and the work behind it)! I was hoping to clarify / discuss a couple of points from it:

• Requiring PKCE for clients means the implementation will not be SMART v1 compliant.
  • One implication to keep in mind is for US customers and ONC patient-facing app requirements / certification (e.g., that won't pass).
  • Outside of that ruling, or as additional flows, this can and has been done (e.g., for a class of apps that aren't patient-facing).
  • I know that vendors have done this (feel free to chime in), but wanted to be clear on the limitations.
• This should/will* be different in SMART v2 (Coming Soon (tm)) (*: it is currently in the spec and has not been a point of contention - I'm leaving the 'should' because nothing is set in stone until publication).
• Could you describe a bit more of the interaction between PKCE and refresh tokens (not allowing refresh tokens without PKCE / confidential client)? AFAICT, this just prevents someone who snooped on the authorization code and was able to exchange for an access token from renewing it. Is that correct, or am I missing something else?

Also, my local recording did work. It's via Jitsi, so your recording is likely better quality if it worked, but all the text appears readable and the audio came through clearly. Please just let me know if you want/need it posted.

Dan Cinnamon (Feb 18 2021 at 22:20):

Thank you @Gino Canessa! I did a quick gut check of my video, and it does look like it came through as well- I just wanted to do a little bit of cropping at the beginning and end and I'll post it before I begin the weekend. I'll let you know if I have issues though.

I appreciate the follow-up on the PKCE topic as well- I think your understanding there is accurate, in that both PKCE and confidential clients give us some confidence that the tokens actually wound up in the right hands (with confidential still being more secure if it's possible to be used).

So it has been Okta's stance that given the sensitivity of the refresh token that it's not something we're minting without the client falling into one of those 2 buckets (confidential, or public w/ PKCE).

Part of my proxy architecture would allow me to bypass that requirement if needed, and it would do so by having the /token proxy performing client authentication on behalf of the public client that doesn't use PKCE (Okta wouldn't know it as a public client- it would know it as a confidential one).

Venu Gopal (Feb 19 2021 at 00:49):

Thank you @Dan Cinnamon for the presentation. I am implementing something similar for India. It isn't standard yet here, we are encouraged to learn from SMART (v1/v2) and are trying reference implementations. Most of the patient apps are mobile with a guidance to use PKCE. I have some questions for you. If these are answered before, please direct me there

1) Is there an introspection endpoint the FHIR resource server can access ?
2) How would a device flow be ?
3) How do you support opaque tokens ?
4) Is there a plan to support EHR launch ?
Any guidance on "intent" of launch context is appreciated. For example, break the glass (BTG)/emergency access to a patient record without consent. I understand Audit security flag, but I am looking more in terms of how can a record be accessed ? How can the requester be downscoped to access only that patient's record and not anything else, until the audit is on

Thanks again

Dan Cinnamon (Feb 19 2021 at 20:29):

Hi @Venu Gopal , welcome! (Sorry hit send too soon- i'll send response soon)

Dan Cinnamon (Feb 19 2021 at 22:58):

1) Is there an introspection endpoint the FHIR resource server can access ?

Yep- there is an introspection endpoint that Okta offers out of the box that is called out in my metadata endpoints.

2) How would a device flow be ?

Can you clarify? Do you mean OAuth2 device code flow? Or machine to machine client credential flow?

3) How do you support opaque tokens ?

I'm not- I'm always using JSON web tokens.

4) Is there a plan to support EHR launch ?

Not at this time- I've given it some thought on how I might do it, so if there's big demand in the future I might take that leap.

Any guidance on "intent" of launch context is appreciated. For example, break the glass (BTG)/emergency access to a patient record without consent. I understand Audit security flag, but I am looking more in terms of how can a record be accessed ? How can the requester be downscoped to access only that patient's record and not anything else, until the audit is on

I have a feeling I'm not going to provide you with a sufficient answer right out of the gate, but here goes my first attempt (and maybe others with far more experience can jump in!):
So in general, any of the launch response parameters, by themselves, are purely meant as "hints" to the application- and by themselves are not security enforcement.
The "patient" response is special though, in that it does inform the application what patient the access token has access to- but it's still just a hint, the application can choose to ignore it (but won't be very useful if it does ignore it).
The resource server is still responsible for introspecting the token, and furthermore checking/enforcing what "records" it can access. Exactly how that is determined is left to the implementation.
In my particular implementation, since I'm using signed JWTs for my access tokens, I am also including the selected patient id as a claim within the access token, so it will be easy for the resource server to determine what patient the token is scoped to during the introspection process.
For the intent response in particular, seems like it can be anything you want, and so I'd think to derive any value from that at all, the organization hosting the resource and authorization server would need to publish what their authorization server might send for it, so application developers can account for it in their applications.

Alan Viars (Feb 22 2021 at 14:14):

@Dan Cinnamon Can you share the recording?

Alan Viars (Feb 22 2021 at 14:14):

@Josh Mandel Yes please add me to the SMART Health Cards thing.

Dan Cinnamon (Feb 22 2021 at 14:36):

Hi @Alan Viars, definitely will. I'm working with @Gino Canessa to see which of our recordings will be best to share. I found out on Friday that my recording only has my audio in it (so the conversations are very one sided- ha). So if Gino's recording is better, I'm hoping we can use his, otherwise mine is better than nothing and I'll share it!

Gino Canessa (Feb 23 2021 at 22:00):

Hi all, here is a link to the recording of Dan's presentation I have. I'll apologize that it doesn't have audio of me speaking (discovered a mic configuration issue), but on the balance I didn't say much =).

Cheers,
-Gino

(tags for people I've seen ask: @Alan Viars @Josh Mandel @Venu Gopal )

Venu Gopal (Mar 01 2021 at 07:17):

Hi @Dan Cinnamon no problems. Thank you for your message and responses

The question on device flow - I was interested in device flow as there mayn't be an option to key in login information. For example a patient may be equipped with a IoT device (a glucometer) and sync with patient's mobile app. The glucometer may have to post Observations at frequent time intervals to the app. How would the device authenticate with the patient app ? Or would that be M2M ? I am not an expert of M2M. So if you can offer some insights that would be of help

Dan Cinnamon (Mar 01 2021 at 15:03):

Hi @Venu Gopal,

I see- so the device code flow is great in use cases where a headless device (or at least input limited device), has the ability to directly communicate with an API from your service. One of the best examples of this would be a smart TV- authenticating with your streaming service in a user friendly way by allowing the user to perform the actual login with a computer/mobile device rather than typing with their TV remote on a virtual keyboard. At the end of the device code flow process, the IoT device actually has OAuth tokens in hand that it can use for subsequent authorization directly to an API.

A few considerations on that though:
1- For device code flow, the device does at least need to display a code to the user- perhaps 8 characters or so. Will your device have any display at all? Even an old LCD panel like you might find on a 30 year old wrist watch will do- but it does require something.

2- Also in device code flow, the device does need to communicate directly with the authorization service to obtain tokens and make API calls.

I haven't designed a system like this personally, so please just take this as initial thoughts- but I think you should first start with who the actual OAuth2 client is (who/what is actually calling the FHIR API). From your description, it sounds to me like perhaps your mobile app is the actual OAuth2 client to the FHIR API, and so the mobile app is the one that would do the SMART flow.

Venu Gopal (Mar 07 2021 at 03:44):

Thank you @Dan Cinnamon you are right. I asked if more as a forward looking one. As of now the plan is to connect bluetooth enabled devices connect via the mobile app. Thank you so much for the insights

Lee Surprenant (Jun 16 2021 at 12:55):

A long while back, I took a TODO to open up some Keycloak extensions that we were using in support of SMART App Launch. I did that a few months ago but never got around to announcing it here. If you are interested in SMART support for Keycloak, please have a look and let me know what you think: https://github.com/Alvearie/keycloak-extensions-for-fhir

---

Last updated: Apr 12 2022 at 19:14 UTC