Profile picture

A link, not an image

With the profile_photo scope granted — and only if the person has a picture on file — userinfo adds a picture claim. It is a URL: <issuer>/v1/userinfo/picture. It is not a public URL and it is not the bytes.

GET /v1/userinfo/picture answers to the same access token, with the image bytes, its Content-Type, an ETag of the SHA-256 checksum, and Cache-Control: private, no-store. The moment the person disconnects, the next request fails like any other userinfo call — instead of the image living on in a cache.

curl -s "$UNIFYID_API/v1/userinfo/picture" \
  -H "authorization: Bearer $ACCESS_TOKEN" \
  -o picture.bin -D -

It is restricted

profile_photo is a restricted scope, like date_of_birth: eligible testers and test identities can exercise it in Sandbox, and turning it on for a live application is a material change that a reviewer reads. Every read of the picture is recorded as a disclosure of picture to your application, in the same transaction, so the person can see who looked at their face and when.

Without the scope, the endpoint answers insufficient_scope, status 403. Without a token, invalid_token, status 401.

Test identities have pictures too

A test identity's picture is served the same way, from the same row. A developer building an avatar can see their own synthetic person's face through the production code path. POST …/test-identities/{testIdentityId}/avatar sets one; GET and DELETE read and remove it.