i4mi / midata.js Goto Github PK

In order to prevent csrf attacks

https://tools.ietf.org/html/rfc6749#section-4.1.1
https://tools.ietf.org/html/rfc6749#section-10.12

TODO:

• Send 'state'-parameter (maybe random string?) with client authorization request. If the information was present the server will thereafter return the value again within it's response.
• Compare the received state param with the original one.

Zur Zeit werden nur die "registrierten" Ressourcen (z.B. BodyWeight) als Klassen instanziiert, die anderen werden als JSON-Objekt instanziiert.

Alle Ressourcen sollten als Klasse instanziiert werden (z.B. MedicationStatement, Observation oder zumindest Resource). Dafür muss die "Registrierung" ausgebaut werden: zusätzlich zum Code muss auch den Ressourcetyp in der Mappingtabelle aufgenommen und berücksichtigt werden.

Unlike the MIDATA API the FHIR API does not provide specific user information after successful authentication. This information is needed though in order to query records later on. Therefore, the library needs to be extended so that this information is obtained and securely stored during the applications' 'logged in' scope.

TODO

• Upon retrieval of access_token ( GET -> /fhir/Patient)
• Extract and store user info (_id & name) into user object and invoke _setLoginData()

See FHIR Vital Signs Profile http://build.fhir.org/observation-vitalsigns.html

Fix in "master" branch as well as in "feature"

In order to prevent MIDATA from creating waste consents during each application's initial authentication process using the same device, the application itself should explicitly send the device_id of the associated device to the platform.

Therefore, the MIDATA.js authenticate() method needs to be extended so that it allows for indication of a specific device_id param.

Implement proof key for code exchange in order to prevent session thievery.

According to https://tools.ietf.org/html/rfc7636

TODO:

• Create verifier
  code_verifier = high-entropy cryptographic random STRING using the
  unreserved characters [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~"
  from Section 2.3 of [RFC3986], with a minimum length of 43 characters
  and a maximum length of 128 characters.

• Derive code challenge from code verifier (e.g. SHA256 or plain).

  The client then creates a code challenge derived from the code
  verifier by using one of the following transformations on the code
  verifier:

  plain
  code_challenge = code_verifier

  S256
  code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

• Send code challenge with the authorization request.
  Note: At this point also the state param needs to be considered (see issue #3 ).

  This includes the following additional parameters:

  code_challenge
  REQUIRED. Code challenge.

  code_challenge_method
  OPTIONAL, defaults to "plain" if not present in the request. Code
  verifier transformation method is "S256" or "plain".

  The server stores the code information internally.

• Upon receipt of the Authorization Code, the client sends the Access
  Token Request to the token endpoint. In addition to the parameters
  defined in the OAuth 2.0 Access Token Request, it sends the following parameter:

  code_verifier
  REQUIRED. Code verifier

  The "code_challenge_method" is bound to the Authorization Code when
  the Authorization Code is issued. That is the method that the token
  endpoint MUST use to verify the "code_verifier".

• Server Verifies code_verifier with stored challenge information.

  BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge

  If the "code_challenge_method" "plain", they are
  compared directly, i.e.:

  code_verifier == code_challenge.

• Upon success, the server issues the access and refresh tokens to the client.

"We noticed that the user is taken to Safari to sign in or register for an account, which provides a poor user experience.

Next Steps

To resolve this issue, please revise your app to enable users to sign in or register for an account in the app.

We recommend implementing the Safari View Controller API to display web content within your app. The Safari View Controller allows the display of a URL and inspection of the certificate from an embedded browser in an app so that customers can verify the webpage URL and SSL certificate to confirm they are entering their sign in credentials into a legitimate page."

More information:
https://medium.com/@jlchereau/stop-using-inappbrowser-for-your-cordova-phonegap-oauth-flow-a806b61a2dc5