The SCIM user endpoint

A single endpoint returning the authenticated user’s own record — “SCIM Me” in SCIM 2.0 terms. Oase calls it like this:

GET {scim_uri}
Authorization: Bearer {token}

There is exactly one route, no path parameters: you identify the user from the bearer token. Oase does not use any other part of the SCIM protocol — no /Users search, no /Groups resource, no filtering, no pagination, no PATCH, no service-provider config. If you already run a full SCIM 2.0 server, exposing /Me is enough; if you don’t, implementing just this one GET is enough.

Response

gzip is mandatory

The response body must be gzip-compressed. The current Oase client unconditionally gunzips the body before decoding it — it does not send an Accept-Encoding header and does not check Content-Encoding. Always compress, regardless of request headers, or the sync will fail.

The decompressed body is a JSON object shaped like a SCIM 2.0 core User:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "83bb096a-d54f-45ee-8220-2a203ac22f1e",
  "name": {
    "givenName": "Anders",
    "familyName": "Lemke"
  },
  "photos": [
    { "value": "https://partner.example/avatars/anders-big.jpg", "type": "photo" },
    { "value": "https://partner.example/avatars/anders-small.jpg", "type": "thumbnail" }
  ],
  "groups": [
    {
      "value": "c32598c2-eec9-40e9-9226-0c63c9ca556c",
      "display": "Beach cleanup — Amager Strand",
      "type": "direct"
    },
    {
      "value": "9a1f7c4e-2b3d-4e5f-8a6b-7c8d9e0f1a2b",
      "display": "Soup kitchen volunteers",
      "type": "direct"
    }
  ]
}

Fields Oase actually reads:

Field	Used for	Notes
id	The user’s external id	Any stable string.
name.givenName, name.familyName	The user’s display name in the realm	Concatenated with a space; a blank name is left untouched.
photos[]	The user’s avatar	The entry with "type": "photo" is preferred, else the first entry. value must be an absolute, publicly reachable URL — it is served to clients verbatim, never proxied or downloaded. A photo the user has uploaded themselves in Oase is not overwritten by the external one.
groups[]	Sub-group membership	See below. Duplicate entries (same value) are tolerated and de-duplicated.

Everything else (emails, phoneNumbers, addresses, userName, enterprise extensions, …) is accepted and ignored.

For each group entry:

Field	Used for	Notes
value	The group’s stable identity	The sub-group space’s id in Oase is derived deterministically from it. Never change a group’s value — a changed value is a brand-new group space, and members are silently removed from the old one on their next sync.
display	The group space’s name	Re-applied on every sync, so renaming a group on your side propagates. An empty or missing display leaves the current name.
type	—	Ignored.

Errors

Any non-success (or malformed) response makes the sync for that user log an error and abort; the user’s existing memberships are left untouched. A 401/403 for an expired token behaves the same way — see the token lifetime note.