Security
Access that holds up
Every request is checked on the server against the role you hold and the records you own. Authentication and authorisation are separate, and both are enforced on each endpoint.
- Role-based access
- Each account is an admin, doctor, patient or receptionist, and the API checks the role before it answers.
- Token sessions
- Signing in issues a short-lived access token and a refresh token, so a session expires instead of lingering.
- Records stay with their owner
- Appointments, prescriptions and bills are scoped to the doctor and patient they belong to, so another clinic's records stay out of reach.
- A documented API
- Every endpoint is described by an OpenAPI schema, with Swagger UI and Redoc served beside the app.
In the detail
How the checks are built, from the account you sign in with to the schema that describes the API.
- Roles
- Every account is an admin, doctor, patient or receptionist. Each role has its own permission on the server, and a request is rejected before the view runs if the role does not match.
- Tokens
- Signing in exchanges an email and password for a short-lived access token (60 minutes) and a refresh token (1 day). Requests carry the access token as a Bearer header, and an expired access token is renewed with the refresh token instead of asking for the password again. Tokens are signed with HS256.
- Ownership
- Records stay with their owner. A doctor can only change an appointment, prescription or bill that belongs to them, and a patient only sees their own, so another clinic's records stay out of reach.
- Schema
- The whole API is described by an OpenAPI schema generated with drf-spectacular. Swagger UI is served at the API root and Redoc beside it, so the contract can be browsed without reading the source.
See it for yourself
Create an account, or read the endpoints in the OpenAPI schema that ships with the API.