How to obtain access token without OAuth2

[Rob Taylor]

I'm creating an app that will pull EHR data via FHIR services, but my app will not have a user interface and will be server-to-server communication only. It seems that OAuth2 is only necessary for FHIR authorization if you have a person accessing a UI. I can't seem to find any documentation on how to obtain a FHIR access token without using OAuth2. I do see that there is a Backend Services (draft) option, but it appears to not be ready for production use yet. 

Is there a way to simply use a client_id and client_secret for an app to obtain a FHIR access token for accessing EHR data without having to use OAuth2 and without using the Backend Services implementation? For example, is there some way to call the FHIR token endpoint URL (i.e., providing specific POST parameters) to obtain the access token *without* going through the OAuth2 authorization step first (which requires a UI and user authorization)? Thanks!

[Nikolai Schwertner]

The only way I know around the authorization step in SMART's OAuth profile is if you can obtain a Refresh Token from the auth server and use it in your app. With a valid refresh token, your app can go straight to the token exchange step and obtain an access token.

-Nikolai

On 3/28/17 12:25, Rob Taylor wrote:

I'm creating an app that will pull EHR data via FHIR services, but my app will not have a user interface and will be server-to-server communication only. It seems that OAuth2 is only necessary for FHIR authorization if you have a person accessing a UI. I can't seem to find any documentation on how to obtain a FHIR access token without using OAuth2. I do see that there is a Backend Services (draft) option, but it appears to not be ready for production use yet. 

Is there a way to simply use a client_id and client_secret for an app to obtain a FHIR access token for accessing EHR data without having to use OAuth2 and without using the Backend Services implementation? For example, is there some way to call the FHIR token endpoint URL (i.e., providing specific POST parameters) to obtain the access token *without* going through the OAuth2 authorization step first (which requires a UI and user authorization)? Thanks!

--
You received this message because you are subscribed to the Google Groups "SMART on FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michele Mottini]

To the best of my knowledge the only standard to do server-to-server authentication for FHIR is that Backed Services authorization you already found. 

Simply using client id + client secret - or other password-based methods - is frowned upon because relies on distributing and transmitting shared secrets.

Mutual TLS would be another option, but I never saw it discussed or implemented for FHIR servers

Our server implement Backend Services authorization, we do use it in production and you are welcome to try it against our test server (look for CareEvolution at http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing) - but most of the big vendors seems focused on user access now, not server-to-server, so you might not see much other servers accessible in the same way

  - Michele

  CareEvolution Inc

[Adrian Gropper]

Server-to-server FHIR is the reason for the HEART workgroup. Please check us out: http://openid.net/wg/heart/

Adrian

--
You received this message because you are subscribed to the Google Groups "SMART on FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/

[Rob Taylor]

Thanks for the help, everyone!

[Luiz Omori]

Regarding the above mentioned draft page:

1. There is a newer version of the RFC link embedded in the page: https://tools.ietf.org/html/rfc7523

2. In the diagram under "Obtaining an Access Token", shouldn't the "grant_type" parameter be "authorization_code", per RFC 7523, section 2.2? Yes, I find that weird too...

Regards,

Luiz

[Justin Richer]

Luiz,

In section 2.2 of RFC7523, the JWT assertion is being used for client authentication. This can be used in concert with *any* grant type that requires the client to authenticate. The example in the RFC is authorization_code, but its use in SMART (and HEART) is with client_credentials.

 — Justin

[Luiz Omori]

Ah, I see, that makes more sense.

Regards,

Luiz