Ability to query for identity properties without admin rate throttling

[blackbird-hank]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

xenodochial-mestorf-alar1uohvl

Describe your problem

We've been using Ory as a single source of truth for user properties, avoiding replication within our application data so as not to increase our exposure to PII. The key properties in our application are user email address and 'display name', both of which are retained solely with Ory.

We have a need to surface this data to our front end, however, in various user listings pages (e.g. listing users who are a member of a team). To achieve this, we've been pulling these properties via our backend calling the https://www.ory.sh/docs/reference/api#tag/identity/operation/getIdentity endpoint

The issue we've encountered is that this solution does not scale, due to rate limiting on the Ory side. Indeed, it would seem this API is not expected to be used for the kind of realtime, user facing use flow we're currently employing it for.

We can address the problem by replicating these properties in our application, but at the cost of maintaining this PII ourselves.

As such, it would be desirable if Ory supported identity property retrieval via an API for such real time use cases such as the one I've described.

Describe your ideal solution

The existence of an API for retrieval of identity properties for any user with rate limiting aligned with the /sessions/whoami (etc) APIs (ref)

Bonus points if the API could accept a set of identities IDs to retrieve properties for

Workarounds or alternatives

Replicating the PII our side, avoiding the need to query Ory for such flows

Version

Ory Network (i.e. your managed, cloud solution)

Additional Context

No response

[aeneasr]

Do you need the authenticated users' property or properties of a random list of users? Would it be OK if data is a bit stale (~4-5seconds on average)?

[blackbird-hank]

Do you need the authenticated users' property or properties of a random list of users? Would it be OK if data is a bit stale (~4-5seconds on average)?

Yup, a random list of users. Live data would be best obviously, but we could live with some latency I suspect.

[aeneasr]

Removed my last comment, since you already reached out there. At the moment we can't really change the rate limits as it affects all projects. For now what I can recommend would be using an in-memory cache with TTL to reduce the number of calls.

You may also want to use web hooks post login/signup to update data in the cache.

Another option is to upgrade the tier which has higher rate limits.