Self-Hosted Identity Infrastructure
Deployed Ory Kratos and Hydra to serve 500K+ users with custom authentication flows, multi-factor authentication, and enterprise SSO integration.
OAuth2 Authorization Server
Built OAuth2 authorization server using Ory Hydra for third-party API access, handling 1M+ token requests daily with consent management and token rotation.
Relationship-Based Access Control
Implemented Ory Keto for complex authorization with relationship-based permissions, supporting fine-grained access control across millions of resources.
HIPAA-Compliant Identity System
Deployed self-hosted Ory infrastructure for HIPAA compliance, ensuring patient data remains in controlled infrastructure with audit logging and encryption.
What Ory Developers Actually Build
Ory is not a single product but a suite of identity and security services. Understanding what developers build helps you hire effectively:
Identity & Authentication (Ory Kratos)
User Identity Management
- User registration and login flows - Customizable authentication UI with email/password, social login, passwordless (WebAuthn), and multi-factor authentication
- Session management - Secure session handling with configurable lifetimes, refresh tokens, and session invalidation
- User profile management - User data models, profile updates, and identity verification workflows
- Account recovery - Password reset, account recovery, and email verification flows
Real-world examples: Companies building identity as a core product, SaaS platforms requiring custom authentication flows, organizations with strict data residency requirements
OAuth2 & OpenID Connect (Ory Hydra)
Authorization Server
- OAuth2 server - Full OAuth2 implementation supporting authorization code, client credentials, and refresh token flows
- OpenID Connect provider - OIDC-compliant identity provider for single sign-on (SSO) scenarios
- Consent management - User consent flows for OAuth2 authorization requests
- Token management - JWT and opaque token issuance, validation, and revocation
Real-world examples: API platforms requiring OAuth2 for third-party access, microservices architectures needing centralized authorization, enterprise SSO implementations
API Authorization (Ory Oathkeeper)
API Gateway with Authorization
- Request authentication - Validates tokens and authenticates API requests
- Authorization policies - Rule-based access control for API endpoints
- Rate limiting - Protects APIs from abuse and enforces usage limits
- Request transformation - Modifies requests before forwarding to upstream services
Real-world examples: Microservices architectures, API platforms, multi-tenant SaaS applications requiring fine-grained access control
Permission Engine (Ory Keto)
Relationship-Based Access Control
- Role-based access control (RBAC) - Traditional role and permission models
- Attribute-based access control (ABAC) - Policy-based authorization using user attributes
- Relationship-based access control (ReBAC) - Graph-based permissions using relationships between resources
- Permission evaluation - Fast permission checks for authorization decisions
Real-world examples: Complex authorization requirements, multi-tenant systems, document management systems, collaboration platforms
Ory vs. Auth0 vs. Clerk vs. Okta
Understanding the identity platform landscape helps you evaluate what Ory experience actually signals:
Platform Comparison
| Aspect | Ory | Auth0 | Clerk | Okta |
|---|---|---|---|---|
| Deployment Model | Self-hosted (open source) | Managed SaaS | Managed SaaS | Managed SaaS |
| Data Sovereignty | Complete control | Vendor-controlled | Vendor-controlled | Vendor-controlled |
| Customization | Full source code access | Extensive (Rules, Hooks) | Moderate (components) | Extensive (Workflows) |
| Operational Overhead | High (you operate it) | Low (managed) | Low (managed) | Low (managed) |
| Cost Model | Infrastructure costs only | Per MAU | Per MAU | Per user/feature |
| Enterprise Features | You build them | Excellent (SAML, SSO) | Limited | Excellent (SSO, MFA) |
| Best For | Data sovereignty, compliance, custom needs | Enterprise, complex auth | Startups, React apps | Enterprise, SSO focus |
| Learning Curve | Steep | Moderate | Low | Moderate |
What This Means for Hiring
The underlying identity concepts are identical across platforms. OAuth2, OpenID Connect, JWT tokens, session management, and security best practices work the same way whether you're using Ory, Auth0, or Okta. The differences are in:
- Deployment model: Ory is self-hosted, others are managed SaaS
- Operational complexity: Ory requires DevOps expertise, others are managed
- Customization depth: Ory offers source-level customization, others provide APIs and hooks
- Data control: Ory keeps data in your infrastructure, others store it externally
Don't filter candidates based on which identity platform they've used. Instead, assess:
- Do they understand OAuth2 and OpenID Connect deeply?
- Can they explain session management and token handling?
- Do they recognize security implications of identity decisions?
- Have they worked with self-hosted infrastructure or complex identity systems?
When Ory Experience Actually Matters
While we advise against requiring Ory specifically, there are situations where Ory familiarity provides genuine value:
High-Value Scenarios
1. Existing Ory Infrastructure
If your organization already runs Ory (Kratos, Hydra, Oathkeeper) in production with complex configurations, Ory experience accelerates onboarding. However, any developer with deep identity experience (Auth0, Okta, custom OAuth2) adapts quickly—the protocols are identical.
2. Self-Hosted Identity Requirements
If you're building identity infrastructure from scratch and require self-hosting (data sovereignty, compliance, cost control), Ory experience helps. But this is rare—most companies start with managed platforms and migrate to self-hosted only when necessary.
3. Complex Authorization Requirements
If you need relationship-based access control (ReBAC) or highly customized authorization logic, Ory Keto experience is valuable. However, most applications don't need this complexity—standard RBAC or ABAC works fine.
4. Open-Source Identity Platform
If you're building an identity product or platform that requires source-level customization, Ory's open-source nature matters. But this is niche—most applications use identity as infrastructure, not a product.
When Ory Experience Doesn't Matter
1. Standard Authentication Needs
For typical user registration, login, and session management, any identity platform works. Ory experience provides no advantage—Auth0, Clerk, or Firebase Auth are equally capable and easier to operate.
2. Managed Platform Preference
If you prefer managed identity platforms (most companies do), Ory experience is irrelevant. You'll use Auth0, Clerk, or Okta, which are simpler to operate and require less expertise.
3. Prototype or MVP Stage
Early-stage products benefit from managed platforms that require minimal setup. Don't require Ory experience if you're not committed to self-hosted identity infrastructure.
4. Limited DevOps Resources
Ory requires significant operational expertise—Kubernetes deployment, monitoring, scaling, security patching. If your team lacks DevOps capacity, Ory isn't the right choice regardless of developer experience.
The Modern Ory Developer Profile
They Think in Protocols, Not Just APIs
Strong Ory developers understand identity protocols at a deep level:
- OAuth2 flows - Authorization code, client credentials, refresh token, and when to use each
- OpenID Connect - ID tokens, user info endpoints, and OIDC discovery
- JWT structure - Claims, signing, validation, and token lifecycle
- Session management - Secure session storage, refresh patterns, and invalidation strategies
- Security patterns - CSRF protection, XSS prevention, secure cookie handling
They're Security-First Engineers
Identity systems are security-critical. Good developers:
- Understand attack vectors - Session hijacking, token theft, CSRF, XSS, and how to prevent them
- Implement defense in depth - Multiple layers of security, not relying on a single mechanism
- Follow security best practices - Proper token storage, secure session handling, input validation
- Stay current with vulnerabilities - CVE tracking, security updates, and threat modeling
They Operate Complex Infrastructure
Ory is self-hosted infrastructure. Strong developers:
- Deploy and scale - Kubernetes expertise, Helm charts, monitoring, and alerting
- Debug production issues - Log analysis, distributed tracing, and performance optimization
- Manage data - Database migrations, backup strategies, and disaster recovery
- Handle incidents - On-call experience, incident response, and post-mortem analysis
They Balance Control with Complexity
Ory offers control at the cost of complexity. Good developers:
- Evaluate trade-offs - When self-hosted identity is worth the operational overhead
- Simplify where possible - Using managed platforms when appropriate, Ory when necessary
- Document decisions - Why Ory was chosen, how it's configured, and operational procedures
- Plan migrations - Moving from managed platforms to Ory, or vice versa
Core Ory Competencies
Must Understand for Any Ory Role
1. OAuth2 and OpenID Connect
The foundation of modern identity. Strong candidates explain:
- Authorization code flow vs. client credentials flow and when to use each
- ID tokens vs. access tokens and their different purposes
- Token refresh patterns and handling expired tokens
- OIDC discovery and dynamic client registration
2. Session Management
Critical for user experience and security:
- Secure session storage (HTTP-only cookies, secure flags)
- Session lifetime and refresh strategies
- Session invalidation and logout flows
- Multi-device session handling
3. Security Best Practices
Identity systems are high-value targets:
- CSRF protection mechanisms
- XSS prevention in authentication flows
- Secure password storage (hashing, salting, bcrypt/argon2)
- Rate limiting and brute force protection
- Secure token storage (never in localStorage for web apps)
4. Ory Architecture
Understanding the Ory ecosystem:
- Kratos - User identity, authentication flows, session management
- Hydra - OAuth2/OIDC server, token issuance, consent flows
- Oathkeeper - API gateway, request authentication, authorization policies
- Keto - Permission engine, RBAC/ABAC/ReBAC models
5. Self-Hosted Operations
Ory requires operational expertise:
- Kubernetes deployment and scaling
- Database management (PostgreSQL)
- Monitoring and alerting (Prometheus, Grafana)
- Backup and disaster recovery
- Security patching and updates
Ory vs. Managed Platforms: The Trade-offs
When Ory Makes Sense
1. Data Sovereignty Requirements
If regulations or policies require data to remain in your infrastructure (GDPR, healthcare, government), Ory's self-hosted model is necessary. Managed platforms store data in vendor-controlled systems.
2. Cost at Scale
For very large user bases (millions of users), self-hosted Ory can be significantly cheaper than per-MAU pricing from managed platforms. However, factor in operational costs—DevOps time isn't free.
3. Customization Needs
If you need identity behavior that managed platforms can't provide (custom authentication flows, unique authorization logic), Ory's source-level customization is valuable. But this is rare—most needs are met by platform APIs.
4. Building Identity as a Product
If identity is your product (you're building an identity platform), Ory provides a solid foundation. You can customize and extend it without vendor constraints.
When Managed Platforms Are Better
1. Standard Authentication Needs
For typical user registration, login, and session management, managed platforms (Auth0, Clerk) are simpler and faster to implement. You'll be productive in days, not weeks.
2. Limited DevOps Resources
If your team lacks Kubernetes expertise or operational capacity, managed platforms eliminate operational overhead. You focus on application code, not infrastructure.
3. Rapid Development
Managed platforms provide UI components, SDKs, and documentation that accelerate development. Ory requires building UI, integrating SDKs, and extensive configuration.
4. Enterprise Features
Managed platforms offer enterprise features (SAML SSO, compliance certifications, support) out of the box. With Ory, you build or integrate these yourself.
Recruiter's Cheat Sheet
Technical Terms to Know
| Term | What It Means | Why It Matters |
|---|---|---|
| Kratos | Ory's user identity and authentication service | The core authentication component |
| Hydra | Ory's OAuth2 and OpenID Connect server | Handles OAuth2/OIDC flows |
| Oathkeeper | Ory's API gateway with authorization | Protects APIs with authentication and policies |
| Keto | Ory's permission and role engine | Handles RBAC, ABAC, and ReBAC |
| OAuth2 | Authorization framework for API access | Industry standard for API authentication |
| OpenID Connect (OIDC) | Identity layer on top of OAuth2 | Enables single sign-on (SSO) |
| JWT | JSON Web Token - a token format | Standard way to represent identity claims |
| Session | Server-side user authentication state | How applications track logged-in users |
| Self-hosted | You run the infrastructure | Complete control but operational overhead |
Conversation Starters That Reveal Skill Level
| Question | Junior Answer | Senior Answer |
|---|---|---|
| "How do you handle token refresh?" | "I call the refresh endpoint" | "I implement refresh token rotation, handle concurrent requests, and gracefully degrade on refresh failure" |
| "What's your approach to session security?" | "I use secure cookies" | "HTTP-only, secure, same-site cookies with CSRF tokens, configurable lifetimes, and secure invalidation on logout" |
| "How do you scale Ory?" | "I add more servers" | "I scale Kratos and Hydra independently, use read replicas for the database, implement caching strategies, and monitor performance metrics" |
Resume Signals That Matter
✅ Look for:
- Specific Ory components they've used (Kratos, Hydra, Oathkeeper, Keto)
- Scale indicators ("managed 1M+ users", "handled 10K auth requests/minute")
- Security-focused language ("CSRF protection", "token rotation", "secure session handling")
- Operational experience ("Kubernetes deployment", "monitoring", "incident response")
- Protocol knowledge (OAuth2, OIDC, SAML)
🚫 Be skeptical of:
- "Ory expert" with no specific components mentioned
- Only managed platform experience (Auth0, Clerk) without self-hosted background
- No mention of security considerations
- No operational experience (Kubernetes, monitoring, scaling)
Common Hiring Mistakes
1. Requiring Ory Specifically
Ory experience is rare. Requiring it unnecessarily limits your candidate pool. Identity concepts (OAuth2, OIDC, session management) transfer across platforms. A developer skilled with Auth0 or Okta learns Ory quickly.
2. Ignoring Security Awareness
Identity systems are security-critical. Candidates who don't discuss security (CSRF, XSS, token storage, session security) are red flags. Security awareness matters more than specific platform experience.
3. Underestimating Operational Complexity
Ory requires significant DevOps expertise. Candidates need Kubernetes experience, monitoring skills, and incident response capabilities. Don't hire a developer expecting them to learn operations on the job.
4. Over-Engineering Identity
Most applications don't need Ory's complexity. Standard authentication (managed platforms) works fine. Only require Ory experience if you genuinely need self-hosted identity infrastructure.
5. Focusing on Ory Instead of Protocols
OAuth2 and OpenID Connect knowledge matters more than Ory-specific experience. A developer who deeply understands these protocols can work with any identity platform, including Ory.