Create Authorization Request Body

The request body for creating an authorization.

Documentation

Properties

callbackUrlstring✻

The callback URL is where the End-User will be redirected.

format: uri1..2048 characters

Documentation

Example
"https://example.com/callback"

clientIdstring✻

The client ID is a unique identifier for a client.

format: uuid

Documentation

Example
"9352258f-0263-47d1-b9c7-16cd93be7501"

csrftstring✻

The CSRF token is used to prevent cross-site request forgery attacks.

format: uuid

Documentation

Example
"87e3838f-ca02-4d8d-89da-5933ae9a82e6"

scopenull | string✻

Space-delimited, case-sensitive list of <action>:<scope> permissions, such as read:name.

A client either follows the permissions the End-User has approved, or fixes a subset of them:

  • omitted or empty — the authorization follows the End-User's approved permissions, so each token carries whatever they allow at the time it is issued. Consent is requested again when the app gains a permission they have not approved.
  • a subset — the authorization is fixed to exactly those permissions. Requesting a permission the app is not allowed to ask for is rejected with invalid_scope, and requesting a different set later replaces the previous authorization.

Changing the requested scope replaces the authorization: any authorization code not yet redeemed, and
every refresh token previously issued to this client for this user, stop working and the End-User authorizes
again. A client that needs different scopes for different surfaces should use a client per surface.

On a refresh request, the value may only narrow what was already granted.

In a token response, this is the scope actually granted — for an authorization that follows the End-User's permissions, the set approved at that moment.

0..1024 characters/^(?:(?:(?:read|write):[\w]+ )*(?:read|write):[\w]+)?$/i

Documentation

Example
"read:name read:bloodGlucose write:bloodGlucose"