Real-World Production Scenarios Document

[FredLackeyOfficial]

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.
• [x] 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

Newcomers to Ory need some type of primer on each of the components as well as a few real-world production-ready deployment scenarios. The currently "5 minute tutorial" only acts as proof that Hydra works. It does nothing to explain HOW it works or what the equivalent would be in a production environment.

Describe your ideal solution

Craft a series of documents showing real-world deployment scenarios, using proper domain names, container instances, and network diagrams showing how one would deploy Hyrdra, Hydra & Kratos, and other product combinations. Clearly identify the flow of data within the public internet, any private calls on a 100% owned back-end, and maybe any private calls from two companies exchanging data (auth flow, etc.). When discussing any product ports or endpoints, provide separate blocks showing the payloads as well as explanations as to how the data is used. And, most importantly, do not use Docker commands for anything since, in the real world away from the tutorial, developers would never use it again (if they must, then also discuss the developer / devops workflows for the tools).

A: Self-Hosted Hydra with Self-Hosted Product Using OAuth The most basic scenario and probably why most people first look for an OAuth provider. They probably have some type of app (WordPress, etc.) and dream of SSO or some type of centralized auth system. Show how to stand up Hyra (only Hydra) on their network and show how to configure at least one product to connect with Hydra. Don't just discuss theory!

B. Self-Hosted Hydra & Kratos with Custom App Needing OAuth / OIDC Show how a developer would build their entrance logic into a custom application with self-hosted Hydra & Kratos instances. Don't just provide a sample consent app! Discuss what is meant to be public and what communication happens privately. Most importantly, discuss the devops workflows, such as when command would need to be run for daily operations (creating new client IDs, etc.).

C. Using Hydra & Kratos with MULTIPLE Apps (Custom & 3rd Party) I predict the most common reason a developer finds Hydra is them wanting to build an "entrance" sequence for MULTIPLE apps in their environment. For example, they may have a WordPress installation and a custom payroll app and need to reuse the same user base for both.

Each of these scenarios builds on the last. They start out with only using Hydra for a third-party self-hosted app needing OAuth. The second forces both the author and developer to understand more of Hydra and what is happening under the hood. And the third scenario allows the reader to see the normal workflow (creating client IDs, etc.) and probably discusses networking and security considerations.

Workarounds or alternatives

No other alternatives exist.

Version

Latest as of 3/31/2022

Additional Context

No response

[aeneasr]

Thank you for the report, I think the ideas here are really good. We are not great at communicating how to use the different components together, also because historically we saw them as isolated components. But of course that is no longer the case and many people want a one-off solution that does it all, especially when they’re new to Ory :)

All of this will take time do develop of course, but it appears that you have some really good ideas already in your head. Maybe we could work together to improve the documentation radically? Not sure if you’re looking, but were also hiring :)

[vinckr]

Continuation of the discussion https://github.com/ory/docs/pull/763#issuecomment-1105142643 in this issue.

Thanks, Fred that is good feedback. I can't summarize it now in a quick comment, but I already have some things in mind that would improve this going forward. In general we need to shape the "journey" people take through the docs a bit better - also taking in account the big difference in familiarity with the software. I think your particular problem with the admin/public ports confusion we can clear up pretty quickly and make it more obvious in multiple parts.

[github-actions[bot]]

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 🙏✌️