The Authentication Roadblock: Why OIDC Integration Makes or Breaks Digital Pathology Tools

The Problem: Gatekeepers Controlling Your Data

Picture this: You’ve built a comprehensive digital pathology infrastructure. Your slides are scanned, stored, and ready for viewing. But here’s the catch – every single application that needs to access those images must go through your primary vendor’s system.

Want to try a new AI analysis tool? You need special integration. Want researchers to use a specialized viewer? Custom API access required. Want to enable multi-site collaboration? Complex vendor negotiations.

This is the gatekeeper problem, and it’s costing digital pathology organizations flexibility, innovation potential, and ultimately, money. Not to mention security, given that most organization will end up working around the primary system, e.g. by granting direct access to the storage.

What Authentication Has to Do With It

At its core, the gatekeeper problem is an authentication problem. When only one application controls who can access your data and how, you’re locked into that vendor’s ecosystem. Every new tool requires their permission, their API, their integration timeline.

But what if multiple applications could authenticate directly to your storage? What if your pathologists, AI systems, and research tools could all access the same data independently, each with appropriate permissions?

This is where OpenID Connect (OIDC) comes in.

What is OIDC?

Think of OIDC as a driver’s license or passport.

When you want to board a flight, rent a car, or open a bank account, you don’t need each business to have a direct conversation with your goverment to check if you are you and if you’re allowed to do that (what a scary thought 😱 btw.). Rather, you show your government-issued ID, and they trust that credential.

OIDC works the same way for digital identity:

Traditional approach (no OIDC):

Each application creates its own user accounts
Users remember different passwords for each system
IT manages separate user databases
New applications require custom integration

OIDC approach:

One trusted Identity Provider verifies who you are
Applications trust that provider’s verification
Users log in once, access multiple applications (Single Sign-On)
Applications never see your actual password

The Technical Foundation

For those interested in how it actually works, OIDC is built on OAuth 2.0, adding an identity layer to OAuth’s authorization framework.

Key components:

Identity Provider (IdP): The service that verifies who you are (like Keycloak, Okta, AWS Cognito or Azure AD)
Applications: Tools that need to verify user identity
Tokens: Digital credentials proving your identity (in JWT format)

When you log in:

You authenticate with your Identity Provider
IdP returns a token proving your identity
Your application uses that token to access resources
Tokens expire automatically for security

The magic is that applications don’t need to know anything about your password, your authentication method, or even how you proved your identity. They just trust the token from the IdP.

Why This Matters for Digital Pathology

Digital pathology has a unique problem: massive data volumes that multiple applications need to access.

Consider a typical scenario:

Pathologists need to view slides
AI systems need to analyze images
Research teams need to extract features for studies
Quality control systems need to perform automated checks
External consultants need access for second opinions

With traditional gatekeeper architectures, all of these must go through a single system. Leading to:

Vendor Lock-In: You can’t easily switch to better viewers or analysis tools. Everything must integrate with your primary vendor’s system, on their timeline, at their price.
Workflow Bottlenecks: All data access flows through one application. When that system is down or slow, everything stops.
Limited Innovation: Want to try the latest AI algorithm from a startup? First, convince your primary vendor to create an integration.
Research Constraints: Multi-institutional collaborations become nightmares of custom integrations. Each institution’s system speaks a different language.

How OIDC Changes the Game

With OIDC-based authentication to object storage, the model flips:

Your data lives in object storage (AWS S3, MinIO, etc.)

Your Identity Provider controls authentication (Keycloak, Okta, etc.)

Applications authenticate to storage directly with user-specific permissions

Using a different viewer is now only a matter of connecting the viewer with your identity provider, so that:

When users open the viewer, it redirects to the identity provider for login
The viewer receives a token proving their identity
The viewer uses that token to get temporary storage credentials
The viewer accesses images directly from storage
The user can seamlessly view the image

–> No involvement from the “gatekeeper” system needed

The same flow works for AI systems, research tools, quality control applications, or any other authorized application.

Real-World Example: AI Research

Assume an organization with one major image management system (IMS) that offers a sophisticated roles and permissions model. It is used to configure exactly who has access to what.

This system however does not run any image processing. Let’s assume they have an internal algorithm team that developed a cell segmentation tool which they want to apply on the images in the IMS. The tool needs to read the image from disk using bioformats or something like pylibCZIrw. In order for it to run on many images in parallel it gets packaged into a container so many processing jobs can be started on-demand. The only requirement is that the processing job has a way of downloading the data.

Now you run into multiple issues:

Does the IMS offer a way to generate a session token or access token that allows the users to pass their authentication to the processing job?
Does the IMS authentication grant raw data access through reasonable APIs? (downloading 80 GB images through http is not reasonable…)

Typically the answer to both questions is “No.”

So in this assumed scenario, the infrastructure team might allow the processing jobs full access to the underlying data storage, just to get things to work. This creates a security nightmare – the processing jobs now have unrestricted access to all data, bypassing the carefully configured permissions in the IMS.

With OIDC, this scenario transforms completely: The processing job authenticates with the organization’s Identity Provider, receives a token scoped to the user who initiated the job, and uses that token to get temporary storage credentials with access limited to only the images that user has permission to view. The IMS permissions model is respected, the infrastructure team maintains proper access control, and the algorithm team gets the direct, efficient storage access they need. No security compromises required.

The Current Landscape: Who Supports OIDC?

Here’s where it gets interesting – and concerning.

AWS S3: Almost, But Not Quite

AWS S3 doesn’t support OIDC directly. Instead, S3 access via OIDC is achieved through AWS Security Token Service (STS) using the AssumeRoleWithWebIdentity API.

The flow:

User authenticates with OIDC provider → JWT token
Application calls AWS STS with JWT token
STS validates token and returns temporary AWS credentials
Application uses temporary credentials to access S3

It’s more complex than native OIDC, but it works. Many organizations successfully use this pattern, especially for CI/CD pipelines (GitHub Actions can deploy to S3 without storing any credentials).

At cytario, we take this further by utilizing SessionTags, which allow group memberships from the OIDC token to be carried over to the AWS session. This enables true resource-based access control – you can configure permissions directly on the data itself. For example, you can tag S3 objects with department or project identifiers and grant access based on group membership, ensuring pathologists only access cases they’re authorized to view.

MinIO: Native OIDC Support

MinIO, the open-source S3-compatible object storage, provides native OIDC support. You can configure it with any OIDC-compliant identity provider (Keycloak, Okta, Azure AD, Auth0, etc.) and it handles authentication directly.

This makes MinIO particularly attractive for:

On-premise deployments needing enterprise SSO
Organizations wanting to avoid vendor lock-in
Multi-cloud strategies
European organizations with data sovereignty requirements

European Cloud Providers: A Critical Gap

After extensive research, I found something surprising: none of the major European cloud object storage providers currently support OIDC authentication for their storage APIs.

Not Scaleway. Not OVHcloud. Not IONOS. Not Exoscale.

They all use traditional access key/secret key pairs. Some support OIDC for logging into their web console or for Kubernetes clusters, but not for the actual storage API.

This is a significant market gap. Organizations wanting European data residency have limited options if they need OIDC-based storage access. The practical choices are:

Use AWS S3 in European regions (with the STS approach)
Self-host MinIO
Accept traditional credential management

Enter Keycloak: The Missing Piece

If you’re going to implement OIDC-based storage access, you need an Identity Provider. While commercial options like Okta and Auth0 work great, there’s a compelling open-source alternative: Keycloak.

Keycloak is a comprehensive Identity and Access Management solution developed by Red Hat that provides:

Core Capabilities:

Single Sign-On across all applications
Full OIDC and OAuth 2.0 support
Integration with existing identity sources (LDAP, Active Directory)
Social login (Google, GitHub, Facebook, etc.)
Multi-factor authentication
Fine-grained authorization

Why Keycloak for Digital Pathology:

Cost Effective: Free (you only pay for infrastructure). For large user bases, this is significantly cheaper than per-user pricing from commercial IdPs.

No Vendor Lock-In: Open source means you’re not dependent on a single vendor. You can move to another solution or even fork the code if needed.

Flexible Deployment: Can run on-premise, in any cloud, or in hybrid configurations. This flexibility matters for organizations with data sovereignty requirements.

Multiple Identity Sources: Can federate identities from Active Directory, LDAP, other SAML providers, and social logins – all in one place.

Production Ready: Organizations use Keycloak to handle 12,000+ requests per second. It’s proven at scale with proper configuration.

The Broader Impact: True Interoperability

OIDC-based storage access isn’t just about technology – it’s about enabling an ecosystem. When applications can authenticate to storage independently, you fundamentally shift the power dynamic in digital pathology.

Consider how this changes the landscape for different stakeholders. Pathologists suddenly have real choice – they can select viewing applications based on features and usability, not based on which vendor has a partnership deal with their institution. If a new viewer offers better annotation tools or a more intuitive interface, they can simply start using it.

AI researchers gain unprecedented freedom. Instead of waiting months for vendor integration timelines, they can deploy new algorithms immediately. The research moves at the pace of science, not the pace of enterprise software sales cycles.

For institutions looking to collaborate, the benefits are transformative. Multi-center research projects no longer require building point-to-point integrations between different vendor systems. Instead, organizations can federate identity across institutions using standard protocols. A pathologist at Institution A can seamlessly access permitted cases at Institution B, all while maintaining proper audit trails and access controls.

Startups and innovators finally get a level playing field. Instead of first securing partnership deals with incumbent vendors, they can build applications that directly serve end users. If your visualization tool or analysis algorithm is genuinely better, you can compete on merit. The barrier to entry drops from “convince enterprise vendor to integrate” to “build something users want.”

Perhaps most importantly, procurement teams can negotiate from a position of strength. When you’re not locked into a single vendor’s ecosystem, you have real leverage. Vendors must compete on features, performance, and price – not on the switching costs they’ve engineered into their architecture.

This is what true interoperability looks like. Not vendor-specific APIs or integration marketplaces, but standard protocols that any application can implement. It’s the difference between a walled garden and an open ecosystem.

Security and Compliance Benefits

Beyond interoperability, OIDC provides significant security and compliance advantages that matter deeply in healthcare contexts.

The most immediate benefit is centralized access control. Instead of managing user accounts across dozens of systems, you have one place to grant and revoke access. When an employee leaves, you disable their account in the Identity Provider and they immediately lose access to all applications – the viewer, AI tools, research platforms, everything. No orphaned accounts, no forgotten credentials scattered across systems.

This centralization extends to audit trails, which are critical for HIPAA and GDPR compliance. Every authentication event, token issuance, and access pattern gets logged. When auditors ask “who accessed this patient’s images last month?”, you have a comprehensive record. The authentication happens through your Identity Provider, so the audit trail is centralized and consistent across all applications.

From a security perspective, OIDC’s use of time-limited credentials is crucial. Access tokens typically expire after 5-15 minutes. This dramatically limits your security exposure – if credentials are somehow compromised, they’re only valid for minutes, not months. Compare this to traditional access keys that might live in configuration files or environment variables indefinitely.

The protocol also enables fine-grained authorization through scoped tokens. You can provide precise control over what each application can access. A viewer application might get read-only access to specific image collections, while an AI processing job gets read access to training data but no access to patient identifiers. These permissions are embedded in the tokens themselves, enforced at the storage layer.

Perhaps most reassuring, you’re not trusting some novel authentication scheme. OAuth 2.0 and OIDC are standards with decades of real-world use, extensive security review, and industry-wide scrutiny. The protocols have been battle-tested at enormous scale by organizations like Google, Microsoft, and financial institutions. When you implement OIDC, you’re building on a foundation that’s been thoroughly validated.

The Path Forward

In Digtial Pathology, the volume of data and the diversity of applications needing access will only increase. AI and machine learning require efficient, parallel access to image datasets. Multi-institutional research demands federated identity management.

Organizations have choices:

Continue with Gatekeepers: Accept vendor lock-in, limited tool choices, and bottlenecked workflows. This is the path of least resistance in the short term, but accumulates technical debt and reduces flexibility over time.

Adopt OIDC-Based Architecture: Invest in identity infrastructure (like Keycloak) and storage platforms supporting OIDC (like MinIO) or standard federation (like AWS S3 with STS). Enable multiple applications to access shared storage. Break free from vendor lock-in.

At cytario®, we’ve made our choice. Our platform is built on OIDC from day one. When you use cytario with MinIO or AWS S3, you’re not locked into our viewer, our analysis tools, or our ecosystem. Your pathologists can use whatever viewing application works best for them. Your researchers can deploy any AI algorithm. Your data remains yours, accessible to any authorized application through standard protocols.

This is what interoperability really means – not marketing buzzwords about “open platforms” while controlling authentication, but genuinely enabling a multi-application ecosystem where the best tools win.

The roadblock isn’t technical. The protocols exist, the implementations are proven, and the benefits are clear. The roadblock is choosing between short-term convenience and long-term flexibility.

Which path will you choose?

Building digital pathology infrastructure and want to avoid vendor lock-in? Let’s talk about how OIDC-based architecture can give you the flexibility to choose the best tools for your workflows.

Further Resources