Authentication (Inbound Connections)


Roche Diabetes Care APIs are secured with mutual TLS for identifying both parties and for securing communication between systems. Roche validates the identity of the client (Middleware) and middleware verifies the identity of the server (Roche).


Introduction


In the typical one-way TLS Authentication, the client verifies the identity of the server. In Mutual TLS Authentication (mTLS), also known as two-way TLS, the server also validates the identity of the client so that they can trust each other.

The Server must authenticate itself to the Client and the Client must authenticate itself to the Server. Both Client and Server present and validate each other’s certificates as part of the handshake in SSL/TLS protocol. Client and Server start with the handshake before the actual API messages are sent / received.


API Authentication


EMR middleware needs to provide the following information to be authenticated in every request:


  • Organization ID: Public identifier of the organization that is consuming FHIR API. If this ID is not available, Roche will provide one.

  • Client ID / Secret: Client ID is a public identifier generated by Roche identifying the organization. Client Secret is a secret known only to the application and Roche ecosystem. This key pair will be provided by Roche.

  • Client Certificate for mutual Authentication: Client certificate and private key for the trusted middleware that is acting on behalf of an Organization. This client certificate will be generated by Roche once the Certificate Request *.csr file is provided by the client.