Access Policies
Introduction
Introduction
This guide explains how Medplum manages authentication tokens and how to implement secure token handling in your applications.
This page helps you choose the correct authentication method for your application, whether it's a browser, a server, or a device. The primary goal is to guide you to the right documentation page based on your use case.
The Medplum API uses standard OAuth2/OpenID authentication. The "Client Credentials Flow" is recommended for machine-to-machine access.
Many SaaS products including popular services like Stripe and Okta support Webhooks, allowing a web application to register a Medplum URL to receive notifications. When a certain event occurs in the source application, such as a new user signup or a change to a record, the source application sends an HTTP POST request to the URL registered by the destination application. This HTTP POST request contains information about the event that occurred.
Some server actions send email messages to users. For example, when a user creates a new account, the server sends a "Welcome" email message. On Medplum's hosted environment, the email will include a link to "https://app.medplum.com/setpassword/...".
A Domain-level Identity Provider (DL-IDP) is a server-level configuration that sets up an external identity provider for all users from a given domain. This identity provider will be used for all Medplum applications the user logs into, including the Medplum App. Domain-level providers are primarily used to ensure that all practitioners access Medplum data via your corporate identity solution.
Along with Google Authentication, Medplum supports other external identity providers using the OAuth2 protocol such as Auth0 and AWS Cognito for end user authentication. This is sometimes known as "Federated Identities".
Medplum supports using Google Authentication as an external identity provider, as well as other external identity providers using the OAuth2 protocol. Google Authentication allows users to log in to your application using their Google profile.
One valuable way to prevent unauthorized data access is to restrict access to clinical data by the user's IP address. This article will discuss the benefits of IP address restrictions and provide a step-by-step guide on configuring these settings in Medplum's AccessPolicy.
There are two different methods to "logout" and revoke access tokens:
The Medplum API supports an "On-Behalf-Of" feature to enable a Customer Server Side App to act on behalf of a Medplum user.
Server Scoped Users
Medplum Projects are the primary mechanism of access control. Projects are isolated containers of FHIR resources that are administered separately, and which can have different settings.
SMART on FHIR’s authorization scheme uses OAuth2 scopes to communicate (and negotiate) access requirements.
This guide walks through how to create and manage users via the Medplum App and via API. Medplum supports multiple authentication options, but always maintains a representation of the user identities, and gives developers control over which authentication method to use for an identity, as well as what access controls are applied.
By default, Medplum uses email address as a unique identifier for a user. When using External Identity Providers, you may instead want to use the external ID rather than email. This document describes the additional changes to use external ID.
Introduction