Authorization requests

An authorization request lets the signed-in user of your app work with other members' data, for example a care team member reviewing the members they look after. The app lists those members when it signs in, your server confirms the user may access them, and StickyHealth grants that access for one hour.

Overview

Only the custom sign-in provider supports authorization requests. With firebase, google or apple, a sign-in that includes an authorization request is rejected with 400 Bad Request.
Your server makes the decision. StickyHealth sends the requested members to your custom token validation endpoint and grants only the members your endpoint returns.
Each grant is a fixed set of permissions to read and update that member's data, and it expires one hour after sign-in. Neither can be changed from the app.

How it works

The app passes an authorization_request in the config of the auth prop, with provider custom.
When the SDK signs in, it sends the token and the request to POST /api/v2.0/auth/token-exchange. The SDK does this for you; there is no separate call to make.
StickyHealth calls your custom token validation endpoint with the token and the requested external_uid values.
Your endpoint checks that the signed-in user may access each requested member and returns the approved entries in its response.
StickyHealth signs the user in and grants access to each approved member for one hour.

Your validation endpoint is registered with us for your organization; the app never sends its URL. See Custom token validation for the request and response your endpoint must handle.

SDK types

auth.config for every provider extends ConfigBase:

{{code.b0}}

Each entry carries only external_uid, the member's id in your system. Permissions and expiry are set by StickyHealth. You can leave api_key out: the SDK already sends the apiKey you gave MiriAppProvider with every request.

Example

tsx

{{code.b1}}

With firebase, google or apple, leave authorization_request out:

{{code.b2}}

Rules and errors

If the sign-in fails, the SDK stays signed out.

Situation	Result
`authorization_request` sent with `firebase`, `google` or `apple`	`400 Bad Request`
`entries` is empty, or an entry has no `external_uid`	Request rejected as invalid
An approved `external_uid` is not a member of your organization	`400 Bad Request`. A member must already exist in StickyHealth, for example by having signed in once, before access to them can be granted.
Your endpoint echoes `authorization_request` with only some of the entries, or with an empty `entries` list	Access is granted only to the entries it returned (none, for an empty list)
Your endpoint returns an error status, invalid JSON or no `sub`	The sign-in fails

Security

Treat the requested list as untrusted input from the app. Your endpoint, not the app, decides who may access whom.
Check each external_uid against your own records of which members the signed-in user may manage, and return only those.
Rate-limit and log your validation endpoint.