Current Node examples of storing user session with a custom storage implementation include generating a unique ID, and distinguishing between user states with this unique ID. This ID is not related to the state key that is generated by the fhirclient library.
In this Pull Request, I am proposing a change where the user of this library can supply their own state key, and this could ostensibly be the same unique identifier that's used for distinguishing users in whatever custom storage solution is implemented. The benefit to this approach is that the state key is already being passed along in the redirect, so one does not have to set cookies in order to recall which user is which. This seems to be more in line with how the state parameter was intended to be used in the OAuth flow.
Current Node examples of storing user session with a custom storage implementation include generating a unique ID, and distinguishing between user states with this unique ID. This ID is not related to the state key that is generated by the fhirclient library.
In this Pull Request, I am proposing a change where the user of this library can supply their own state key, and this could ostensibly be the same unique identifier that's used for distinguishing users in whatever custom storage solution is implemented. The benefit to this approach is that the state key is already being passed along in the redirect, so one does not have to set cookies in order to recall which user is which. This seems to be more in line with how the state parameter was intended to be used in the OAuth flow.