Identity management for patients

A patient’s online identity needs to be uniquely established. This is the only way that authentication and authorization can be centrally and granularly controlled. Modern identity management based on various ICW modules achieves precisely that goal and is a model for protecting and securing patient data.


Dealing with identities and user/login data in terms of security and data protection is already a challenge in controlled environments like hospital networks with just their own employees. It is even more difficult with patients who want to access their information from the Internet. The crux of the task is not only to design a secure IT infrastructure, but also to ensure that a particular computer user matches the person in the patient record. And there is yet another major security issue to keep in mind: The web or mobile app also needs to be authorized to access that patient’s data.

Is it possible to achieve this and still keep the user experience positive? The Internet shows how it’s done: Many of the above requirements can be met using “social login” concepts.


What is a social login?

A social login is nothing more than a single sign-on (SSO) solution, something that is used routinely in enterprise environments. Businesses usually use Kerberos or SAML2-based SSO solutions, which are ideal in an enterprise context but lacking in ideas and the lightness of the new, modern world of the Internet. As a result, a new standard has been established in this area that is both secure and lightweight, and currently has a high level of acceptance in the mobile arena.


OpenID Connect: SSO for the web

OpenID Connect—not to be confused with OpenID 1.0/1.1 or 2.0—is based on the OAuth2 framework and expands it to include systems for authenticating users. Below is a simplified version of the login process:

Simplified login process under OpenID Connect

  1. The user opens a web/mobile app.
  2. The app (referred to as the client or “relying party” (RP)) redirects the user to the OpenID provider’s (OP) authorization URL.
  3. The OpenID provider authenticates the user and authorizes the request.
  4. If successful, the OpenID provider responds to the authorization request with an ID token and in most cases an access token. The ID token is a JSON web token, which may contain cryptographically secured information about the user, such as a unique ID, name, address, or e-mail address.
  5. The RP can either evaluate the information from the ID token or use the access token to send a request to the OP’s UserInfo endpoint in order to obtain information (claims) about the authenticated user. Querying the UserInfo endpoint is recommended because it is easy to implement and does not require any knowledge of cryptography. However, an additional network call is necessary.

Like any other OAuth2 token, the access token can be used as a bearer token to request information from resource servers.

But how can a solution like this handle the challenges mentioned above?


Central and granular access control

As the above authentication process shows, authentication and authorization always take place via the OpenID provider (3.). The OpenID provider is therefore the central entity that ascertains which authorizations are granted to whom and when.

The identity management provider can granularly determine which apps are allowed to access which resources. For example, a prenatal care app could be denied access to psychiatric reports.

In addition, each user can specify exactly which information each app can access. For example, a web app that provides wifi access within a hospital does not necessarily need access to the user’s e-mail address or their first and last name, though it must be able to uniquely identify the user.


Additional protection for medical information

Nevertheless, a central authentication and authorization process (3.) makes it possible to meet the desired security standards in an open ecosystem where there are always new apps and services. One classic example is access to medical information, which can only be granted after a valid multifactor authentication process. Every time authorization is requested, the OpenID provider checks to see whether the rights being requested include access to medical information. If so, a second factor is requested unless one has already been provided. The app is not given access to the medical information until the second factor is successfully authenticated.


Integration with other identity providers

The need for registration is undoubtedly the biggest hurdle with any web or mobile app. The user often has multiple accounts for various services and would rather not have to register for yet another one. However, with OpenID Connect an account can be used not just within one organization, but also to reuse existing login data from other identity providers. This approach has several advantages:

  • No additional registration is required.
  • The user only needs to remember login data for one (existing) account.
  • The identity provider functions as an app (client) in this situation, and uniquely authenticates the user with respect to a different provider. Only the data necessary for login are shared in the process (not credentials). The other identity provider is blocked from accessing the medical data.
  • If the identity provider is a trusted source, such as a bank or insurance company, it can be queried to obtain or confirm the user’s demographic data.



A central identity management system is more than a simple SSO solution. It is the only way to reliably ensure data protection and data security without making unreasonable demands on patients or putting them off. ICW’s Patient Onboarding and App Connect modules are implemented directly on top of OpenID Connect, which accommodates state-of-the-art use scenarios that can be put to productive use by the customers themselves.



Kerberos V5
OASIS SAML V2.0 Standard
Connect 1.0
OAuth 2.0 Authorization Framework
OAuth 2.0: Bearer Token Usage
JSON Web Token (JWT)