Stream: smart
Topic: FHIR-32325
Yunwei Wang (Jul 26 2021 at 20:44):
The FHIR-32325 says
Best practices for app developers include:
My understanding is that "app developer" means both server developer and client developer. Is that correct? It is a little bit confusing that "app" may mean "app in app store".
@Josh Mandel @Dan Gottlieb
Isaac Vetter (Jul 27 2021 at 18:33):
Hey Yunwei, I understand the term "app developer" to apply only to client developers, as in SMART app developer.
Yunwei Wang (Jul 27 2021 at 20:55):
Then I don't quite understand this resolution
"Ensure that refresh tokens are never used more than once"
How could a client ensure a refresh token are never used more than once? Shouldn't that be server's responsibility to ensure that?
Think about this scenario:
Client requests new token with a refresh token X. Server returns a new access token with the same refresh token X. Should client reject that?
Carl Anderson (Jul 27 2021 at 21:57):
Not saying this is a good practice, but couldn't the client refresh their access token normally, but then also try to refresh it again?
If the second attempt works, that's obviously not good. Given that approach, maybe it's not advisable for clients to always try to refresh twice, but maybe it's ok to make the attempt once per session.
Gino Canessa (Jul 27 2021 at 22:07):
I think it is relevant to both, but perhaps could be more explicit:
- Servers should only allow a refresh token to be used once
- be aware of when a refresh token has been used
- reject subsequent requests with the same token
- Clients should expect that a refresh token will only be accepted once
- make sure to update your refresh token with the next one
- gracefully fail if the refresh token has been invalidated (and perhaps warn the user?)
Note: I used 'should' out of conformance context - I think they would be clearer with a set of SHALLs, but these are best practices so... :shrug:
Yunwei Wang (Jul 28 2021 at 00:03):
@Gino Canessa That is also my understanding but the current resolution makes client to take the sole responsibility of that. That makes me feel confused.
Gino Canessa (Jul 28 2021 at 15:40):
@Yunwei Wang Re-reading the ticket, these are additions to 'best practices for app developers', so it makes sense they are focused on client requirements. There is a complementary ticket: FHIR#32324 which has the 'server developer' best practices.
That ticket includes the server direction on expiring refresh tokens.
Yunwei Wang (Jul 28 2021 at 17:12):
That backs to my original question that the refresh token is issued and processed by server. Client has to use what ever server provided. I cannot imagine what client can do otherwise when server decide to reuse refresh token.
Gino Canessa (Jul 28 2021 at 17:24):
If the server returns the same token again, it is a poorly behaved server and the client does not have a different token to use. However, that is quite different from trying to reuse a token from an earlier call, which is what the line says: a client should not try to reuse a token that it has already used (e.g., don't reuse a token). Even in the case of a poorly behaved server, the client can act appropriately in its code (e.g., the token happens to have the same value, but it is a different token).
Especially given that there is no conformance language here, I am not clear on what the issue is. If you think there could be additional clarification, I would suggest adding a comment to the ticket since it has been approved but not yet applied.
Yunwei Wang (Jul 28 2021 at 17:38):
Thanks, I added my comment to the ticket.
Yunwei Wang (Jul 28 2021 at 17:42):
Can we pull this ticket out of approved? If there is too much trouble, I can create a new ticket after it is applied
Gino Canessa (Jul 28 2021 at 17:49):
Re-opening a ticket has a process, this falls under FHIR-I (I believe it needs a vote to open which needs at least 2/3 approval, but not sure beyond that). At this point, I would guess it will be simpler to open a new ticket if you are unhappy with how this one gets applied (I don't think opening one now would do much, since the text hasn't been updated).
With all of that said, point 2) in your comment is exactly what the best practice is trying to say. A well-behaved client should expect that a token is single-use, check for a new refresh token, and then use it instead of trying to reuse an old one.
Last updated: Apr 12 2022 at 19:14 UTC
