Phase out client.OutfacingID

ory / hydra

The most scalable and customizable OpenID Certified™ OpenID Connect and OAuth Provider on the market. Become an OpenID Connect and OAuth2 Provider over night. Broad support for related RFCs. Written in Go, cloud native, headless, API-first. Available as a service on Ory Network and for self-hosters.

Apache License 2.0

15.65k stars 1.5k forks source link

Preflight checklist

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

Describe your problem

Foreign keys referencing the hydra_client table currently use the OutfacingID (column name id) rather than the primary key (column name pk). The OutfacingID is deprecated (see https://github.com/ory/hydra/issues/2781) and redundant.

Describe your ideal solution

Deprecate client_id in the client POST endpoint. IDs are generated by Hydra without the option to be configured.
Use the primary key both internally and in the API.
~~Allow querying with the old IDs by exposing the necessary endpoints as a v1 API.~~ [edit: the API needs to be backward compatible, so this is not an option]
Finally, update the FindInDb method on Flow to use Eager().Find().

~~This solution can be implemented by hashing the legacy IDs and encoding them as UUIDv4.~~

[edit]: The question of how to support the legacy identifiers remains unresolved.

Workarounds or alternatives

A slightly different approach is not to expose a v1 API, but instead to always query for either id or hash(id).

Version

v2.x

Additional Context

No response

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

open a PR referencing and resolving the issue;
leave a comment on it and discuss ideas on how you could contribute towards resolving it;
leave a comment and describe in detail why this issue is critical for your use case;
open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️

ory / hydra