Stream: smart
Topic: authenticating
David Hay (Mar 12 2016 at 02:54):
Whats the appropriate response if the Authorization server declines a request for access - 403 forbidden?
Josh Mandel (Mar 12 2016 at 03:01):
Does the request have an authorization token associated with it (and it's simply no good for what the client is trying to access -- e.g. expired)?
Josh Mandel (Mar 12 2016 at 03:01):
Or is it a request for a protected resource that just includes no token?
Josh Mandel (Mar 12 2016 at 03:05):
The rules are basically (from https://tools.ietf.org/html/rfc6750#section-3.1):
1. Missing token: 401
2. Expired/bad token: 401
3. Good token, but not appropriate for the requested data: 403
Josh Mandel (Mar 12 2016 at 03:06):
These messages should also come with a WWW-Authenticate Response Header response header, and an error code (see the link above)
Josh Mandel (Mar 12 2016 at 03:06):
(We haven't gotten deep into testing/expectations on this front though.)
David Hay (Mar 12 2016 at 19:12):
FYI http://fhirblog.com/2016/03/13/implementing-smart-on-fhir-in-an-ehr/
Josh Mandel (Mar 12 2016 at 19:44):
Awesome! I just retweeted @Keith Boone's link to your post @David Hay. Now to actually read past your intro ;)
David Hay (Mar 12 2016 at 20:39):
now I just need to wait and see if I made any mistakes!
Peter Girard (Mar 14 2016 at 23:11):
Great Article - thank you. In step 6.1, you are making the 'token' call based off of the entry in the Conformance Statement correct? Further, any secret information required by the identity provider will be additionally passed in 6.1, correct?
David Hay (Mar 15 2016 at 00:03):
well, that's the connection between the Resource Server (RS) and the Authz Server (AS), and as they are both 'inside' the EHR the theory is that it shouldn't need to look the end point up. It represents the RS checking with the AzS that the token is valid. As josh said above there are other ways that that could be done without requiring the call - for example the access token could be signed, so the RS knows it hasn't been tampered with...
David Hay (Mar 15 2016 at 00:04):
And by 6.1 the identity has been resolved (step 3) so no other info should be needed at that point...
Peter Girard (Mar 15 2016 at 00:50):
Agreed on the token endpoint lookup. There have been a few identity servers that require extra information during the 'token' call - either a secret (Azure AD) or username/password (Forgerock). This seems to be the only way to keep the extra information out of SPA apps and still use an Auth Code flow. Have you run into a scenario where extra information is required during the token call?
David Hay (Mar 15 2016 at 01:06):
Would that occur in step 3 of the flow? This was intended to be a simple EHR launch where the identity was known at the time of launch. The scenario sounds more like the standalone launch...
Peter Girard (Mar 15 2016 at 13:49):
So, as we understand it, the 'authorize' call happens in step 3, but for these products, do not need extra credentials. That is, it follows exactly the way your flow shows it. But when implementing confidential clients, Azure requires an extra parameter (client_secret - documented https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx). In an SPA implementation, it makes no sense to store this client secret in the browser app. So, we have come to the same sequence you have documented, just with the extra information included in the 'token' call.
Pascal Pfiffner (Mar 15 2016 at 14:37):
@Peter Girard Whether or not a client secret is required is in scope of OAuth2. Using the code grant flow, the secret must be supplied during the code exchange request if one was supplied. You'd usually only supply one to confidential clients, but OAuth2 has been implemented rather liberally in this regard.
Pascal Pfiffner (Mar 15 2016 at 14:38):
One could use dynamic client registration to obtain client key/secret for non-confidential clients, like native apps, so you don't have to embed client key/secret into binaries.
Grahame Grieve (Mar 15 2016 at 17:23):
yes, and dynamic client registration is presently not part of smart. And it sounds a ittle scary
John Moehrke (Mar 15 2016 at 17:49):
it is scary... but so too is fixed passwords in apps... :-) security is hard.
David Hay (Mar 15 2016 at 19:50):
It surely is hard! One of the reasons I think SMART will succeed is that is provides 'recipes' for the common use cases for ordinary developers (like me) to follow in common scenarios...
David Hay (Mar 15 2016 at 19:52):
@Peter Girard - many thanks for your comments - I've updated the post to make the type of flow explicit... (I actually do this stuff so I have something to refer to when I've forgotten the details later!)
David Hay (Mar 16 2016 at 01:16):
Next installment: http://fhirblog.com/2016/03/16/smart-security/
David Hay (Mar 16 2016 at 02:18):
just one more: http://fhirblog.com/2016/03/16/using-smart-to-talk-between-systems/
Pascal Pfiffner (Mar 16 2016 at 08:19):
Well, @Grahame Grieve, SMART at least _encourages_ using DynReg. Our Swift client automatically does dynamically register itself if a) no client id is given when initializing the client and b) the Conformance statement lists a registration endpoint.
https://github.com/smart-on-fhir/Swift-SMART/wiki/Client#dynamic-client-registration
Pascal Pfiffner (Mar 16 2016 at 08:23):
Of course this means anybody can register an app. In C3-PRO we have a mechanism that uses Apple's App Store receipt during client registration, meaning the server can verify with Apple, on a back channel, who this client is.
https://github.com/chb/c3-pro-ios-framework/tree/master/Sources/DataQueue#dynamic-client-registration
This is also not bullet proof though since it's theoretically possible to download an app, extract its receipt and use in in a different app for registration.
Last updated: Apr 12 2022 at 19:14 UTC
