Unable to Launch registered API client in the demo sandbox

Yuva · May 30, 2023, 10:45am

Situation
Prerequisite:

OpenEMR 7.0.1 sandbox (https:// www.open-emr .org/demo/)
Registered React App using FHIR-client JS library (http:// docs.smarthealthit .org/client-js/#smart-api)

I have successfully registered (and also enabled) my react app in the demo sandbox with below details and able to obtain clientId and client secret

Application type - Confidential
Application Context - Multiple Patients Application
App Redirect URI - http://127.0.0.1:3000/appredirecturl
App Launch URI - http://127.0.0.1:3000/launch
Scopes Requested :

Now when I have tried to Launch the application. It successfully redirects to login page, where I have provided the admin credentials, followed by patient selection and scopes access.
The configured react app is not loading and getting the below CORS error

Can anyone help me to resolve the above CORS issue.

OpenEMR Version
I’m using OpenEMR 7.0.1 sandbox (https:// www.open-emr .org/demo/)

Browser:
I’m using: Chrome 113.0 (64-bit)

Search
Did you search the forum for similar questions? Yes, but not found anything related to CORS error

adunsulag · May 31, 2023, 3:44pm

It looks like this is a bug that impacts confidential clients running from a browser context. The bug occurs because the browser does a CORS check when the Authorization header is included in an XHR request. The OPTIONS check for the /token endpoint has an error and returns the 400 status. Clients that strictly check the status code and ignore the headers will run into this problem (such as Chrome).

We’ll have a fix pushed to master and it will be available on the latest development demos soon. Its a bit surprising our automated test suites didn’t catch this but they must not be strictly checking the status code against the CORS headers returned. If you are running your own version of OpenEMR you can patch it this way by adding the following code snippet

        if ($request->getMethod() == 'OPTIONS') {
            // nothing to do here, just return
            $this->emitResponse($response->withStatus(200));
            return;
        }

Here:

github.com

openemr/openemr/blob/75994f1089b0943311d90d7325825a11f1705f9f/src/RestControllers/AuthorizationController.php#L1046

      
        
            }
            
            
/**
             * Note this corresponds with the /token endpoint
             */
            public function oauthAuthorizeToken(): void
            {
                $this->logger->debug("AuthorizationController->oauthAuthorizeToken() starting request");
                $response = $this->createServerResponse();
                $request = $this->createServerRequest();
            
            
    // authorization code which is normally only sent for new tokens
                // by the authorization grant flow.
                $code = $request->getParsedBody()['code'] ?? null;
                // grantType could be authorization_code, password or refresh_token.
                $this->grantType = $request->getParsedBody()['grant_type'];
                $this->logger->debug("AuthorizationController->oauthAuthorizeToken() grant type received", ['grant_type' => $this->grantType]);
                if ($this->grantType === 'authorization_code') {
                    // re-populate from saved session cache populated in authorizeUser().
                    $ssbc = $this->sessionUserByCode($code);
                    $_SESSION = json_decode($ssbc['session_cache'], true);

Just as an aside, are you building your react app to be bundled into a mobile app? If so are you using the secure enclave of the mobile OS to store the client_secret and corresponding refresh / access tokens for your app? If not and you are running this as just a web browser app, it is heavily discouraged from running a confidential client as there isn’t a safe way to keep the refresh token / access token safe. We do refresh token rotation, but there is still a chance for your refresh token and/or client secret to be compromised so its important to understand your risk profile.

Architecture options you could pursue to mitigate this can be found on the draft Best Current Practices for OAUTH2 Browser Based Apps here: draft-ietf-oauth-browser-based-apps-13

I’ve been dealing with this myself with a SMART on FHIR browser app and am debating between the BFF and Token Mediating BFF options mentioned in the BCP link above.

Yuva · June 2, 2023, 6:27am

Hi @adunsulag, I am able to resolve the issue and launch my application. I appreciate you for quick support.
Currently I am just testing the registration and launch flow in open EMR, with a simple react application. I will go through the best practices document you have shared before building the app.
Thanks.