Stream: implementers
Topic: OAuth with async
Lloyd McKenzie (Jul 05 2019 at 18:52):
I have a question about the interaction between Oauth and asynchronous requests. If you have a request from system A to system B that's being authorized by the Patient, what happens if the OAuth token expires before the asynchronous request is delivered? Is that a problem or does the authorization token only matter for the initiation of the request, not the retrieval of the response? (FYI @Jean Duteau @Mark Scrimshire )
David Hay (Jul 05 2019 at 18:54):
Logically, I would have thought it only matters for the initiation...
Lloyd McKenzie (Jul 05 2019 at 19:07):
@Josh Mandel ?
Gino Canessa (Jul 05 2019 at 19:23):
The user is only needed during the authorization process. During that process, System B would request an access token from System A, which after approval would be used for communications on behalf of the user. It is up to System A to determine expiration when granting the access token (and to manage any revocation requests from the user). System A can also include a Refresh Token, so that access can continue without involving the user.
Gino Canessa (Jul 05 2019 at 19:24):
That said, if the token between System A and System B expired and there was no refresh token, the user would need to re-authorize the application.
David Hay (Jul 05 2019 at 19:28):
Leaving the technical issues to one side for the moment though, doesn't it make more sense from the user's perspective that it success regardless? (in the absence of other failure reasons of course)? As the initiator, it would be irritating for me to have to start again just because it took a bit longer than expected to complete...
Lloyd McKenzie (Jul 05 2019 at 19:54):
The asynchronous response I'm looking at might involve human intervention, which can be quite unpredictable in terms of duration. Would I be better off figuring out a different mechanism (i.e. not using async) if the authorization token should be time-limited, but the time to respond should be open-ended?
Mohammad Jafari (Jul 05 2019 at 20:09):
I think the principle is that the Client must be, and continue to remain authorized, for the entire length of the transaction. In this case, the client can acquire a new token (e.g. using a refresh token) but if the token expires and the client cannot demonstrate that it is still authorized, it should not be able to continue the transaction. I think a similar case is when a client is authorized for a workflow which involves multiple steps. If the client's authorization expires at some point during the transaction and it fails to reauthorize itself, then it should not be considered authorized.
Grahame Grieve (Jul 05 2019 at 20:55):
I think it's a policy question, but I think that if a user revoked access, they might find continued access rather surprising
Brendan Keeler (Jul 08 2019 at 02:37):
I think the explanation here is straightforward and the solution elegant: https://nordicapis.com/how-to-handle-batch-processing-with-oauth-2-0/
John Moehrke (Jul 08 2019 at 12:39):
I think the explanation here is straightforward and the solution elegant: https://nordicapis.com/how-to-handle-batch-processing-with-oauth-2-0/
That article is exceptional. It shows a very mature and best-practice. I would highly recommend this.
John Moehrke (Jul 08 2019 at 12:39):
That said, I agree with Grahame, and was about to post my answer "of that is policy" but he got there first.
John Moehrke (Jul 08 2019 at 12:43):
The policy in question needs to consider the risks. In the article Brendan points to, the batch job is making regular payments, so it is making changes. In the case of a FHIR Subscription, it is not making changes, but might be improperly notifying. So there is a different risk profile. The case where the user decides to NOT authorize this subscription, that should be looked to as a new operation against the Subscription. So the most important risk is that when the subscription is going to notify, to be sure the user and app still exist and have a relationship. (Not good to notify a patient that has died).
John Moehrke (Jul 08 2019 at 12:44):
so, it depends on policy and circumstances. Nothing wrong with using the model outlined in the article. But the whole set of risks must be considered, such as the death of the subscriber (payer)...
Josh Mandel (Jul 09 2019 at 01:35):
Catching up here, I think @Mohammad Jafari said it just right. In general @Lloyd McKenzie if you have an authorized async step, there should still be authorization in place at the end of the process. (In Bulk Data we use SMART Backend Services authorization with asynchronous operations, so a client can always fetch new access tokens as needed; with the SMART App Launch framework for user authorization, you'd probably want a refresh token.)
Last updated: Apr 12 2022 at 19:14 UTC
