Authentication

Why DoorFlow's Security is Non-Negotiable

Our unwavering stance on physical access control security

6 mins
Beginner

We hear this occasionally: "But your competitor allows API keys" or "Why can't I just use client credentials?"

Our position is clear and unwavering:

We will not compromise on security to match competitors' looser standards. This guide explains why.

Security is Not a Feature to Toggle

The argument: "Competitor X lets me use API keys, why can't you?"

Our response: Security isn't a competitive feature we adjust based on market pressure. It's a fundamental requirement for protecting:

  • Your customers' physical safety
  • Building access integrity
  • Legal and compliance obligations
  • Audit trail reliability

If a competitor offers weaker security, that's their liability exposure - not a feature we need to match.

We Protect Your Customers, Not Just You

The scenario:

You: "But I'm a trusted developer, just give me an API key."

Us: "What happens when:"

  • Your laptop gets stolen?
  • Your employee goes rogue?
  • Your codebase gets breached?
  • Your customer wants to revoke just your access?
  • Insurance auditors review your security?
  • A compliance audit happens?

API keys can't handle these scenarios. OAuth can.

Different Security Models = Different Liability

Competitors with API keys

•
Single point of failure
•
No granular revocation
•
No user consent audit trail
•
Shared secrets across customers
•
Can't prove who authorized what

DoorFlow with OAuth

•
Cryptographic authorization chain
•
Per-customer revocation
•
Complete consent audit trail
•
Isolated customer access
•
Legally defensible access logs

When something goes wrong (and it eventually does), which position do you want to defend?

Our Commitment is to Your Customers

DoorFlow's customers trust us with physical access to their buildings. We take that responsibility seriously.

We will never

•
Relax security standards to win business
•
Implement "easier" authentication that compromises safety
•
Offer security as a tiered feature
•
Trade customer safety for developer convenience

This isn't negotiable.

We Know This is More Work

We understand these requirements mean more implementation work upfront. You might be thinking:

"I just want to unlock a door. Why all this OAuth complexity?"

Here's the thing: We've made the conscious decision that proper security is worth the extra effort. And we're committed to making that effort as small as possible.

What we provide to help

•
Clear, step-by-step guides for OAuth implementation
•
Working code examples in multiple languages
•
Demo environment for testing
•
Support when you have questions
•
Libraries and SDKs that handle token management

The reality: Once you've implemented OAuth once, it works for all your customers. The upfront investment pays off quickly.

We're here to help you succeed - not to make your life difficult. These requirements exist to protect everyone involved, and we'll support you through the implementation.

Why We're Confident in This Position

Physical security is different

•
One compromised credential = real-world security breach
•
Legal and insurance implications
•
Potential for physical harm
•
Regulatory compliance requirements
•
Multi-year audit trails required

These requirements exist in

•
Healthcare facilities (HIPAA)
•
Financial institutions (PCI-DSS, SOX)
•
Government buildings (FISMA)
•
Critical infrastructure
•
Enterprise security policies

Your integration needs to meet the same standards - whether you're protecting a startup office or a hospital.

Real-World Examples

Why Granular Revocation Matters

Scenario: You build a property management platform serving 50 buildings.

Building A discovers a security issue and wants to immediately revoke your app's access to their building only.

With API keys

•
Can't revoke per-building access
•
Either all 50 buildings keep access or lose it
•
Building A forced to keep your access or break all 50 buildings
•
No good options

With OAuth

•
Building A revokes authorization instantly
•
Other 49 buildings unaffected
•
Clean, surgical revocation
•
Everyone protected

Why Audit Trails Matter

Scenario: Unauthorized person gained building access. Insurance investigation.

Question: "Who authorized this app to control building access?"

With API keys

•
"We gave them an API key"
•
Who approved it? Unknown
•
When? Unknown
•
What permissions? All of them
•
Can you prove consent? No

With OAuth

•
Complete authorization log with timestamps
•
Shows exactly what permissions were granted
•
Proof of explicit user consent
•
Legally defensible audit trail
•
Insurance accepts documentation

Why Short-Lived Tokens Matter

Scenario: Developer's laptop stolen from coffee shop.

With API keys on laptop

•
Thief has permanent access
•
Works from anywhere, anytime
•
Can't tell it's not the real developer
•
Must rotate keys across all customers
•
All integrations break simultaneously
•
Hours or days to fix

With OAuth tokens on laptop

•
Access token expires in 1 hour
•
Refresh token encrypted in database (not on laptop)
•
Thief can't get new tokens
•
Access automatically stops
•
No customer impact
•
No emergency rotation needed

Common Objections (And Our Responses)

"I'm building an internal tool, not a public app"

Internal tools face the same risks:

  • Employee turnover
  • Stolen laptops
  • Insider threats
  • Audit requirements
  • Compliance needs

Your internal tool still needs proper authorization, audit trails, and revocation capabilities.

"This is too complex for my simple use case"

There are no "simple" use cases for physical access control. Even unlocking one door involves:

  • Legal liability
  • Insurance requirements
  • Safety implications
  • Audit obligations
  • Compliance needs

The OAuth overhead is minimal compared to these risks.

"My customers don't care about this"

Your customers may not understand OAuth, but they do care about:

  • Who can access their buildings
  • Ability to revoke access instantly
  • Complete audit trails
  • Compliance with regulations
  • Legal protection

OAuth provides all of this. API keys provide none of it.

"Can't you just make it optional?"

No. Security isn't a feature toggle. We won't create a "simple but insecure" tier that puts customers at risk.

Our responsibility is to protect physical safety, not to offer the path of least resistance.

How This Protects You Too

These requirements aren't just about DoorFlow's customers - they protect you:

Legal protection

•
Audit trail proves proper authorization
•
Clear consent records
•
Defensible security practices

Operational protection

•
Customer revokes = automatic cleanup
•
No manual key rotation
•
Isolated customer environments

Liability protection

•
Can prove you followed best practices
•
Insurance accepts your security model
•
Regulatory compliance built-in

Business protection

•
Customers can't blame you for DoorFlow's security
•
Clear division of responsibility
•
Industry-standard approach

The Industry Standard

DoorFlow isn't inventing these requirements. This is how physical security works:

Smart locks (August, Yale, Schlage)

•
OAuth required
•
No API keys
•
User authorization mandatory

Building access systems

•
Zero Trust architecture
•
Explicit authorization required
•
No shared secrets

Security integrations

•
Time-limited credentials
•
Cryptographic verification
•
Complete audit trails

We're following industry best practices, not being difficult.

Our Promise

We promise

•
Clear documentation to help you implement OAuth correctly
•
Support when you have questions
•
Fair security requirements that serve a real purpose
•
Unwavering protection of customer data and physical safety

We won't

•
Compromise security standards to win business
•
Offer "easy but insecure" options
•
Trade safety for convenience
•
Waver on these principles

The Bottom Line

We are unflinching in protecting DoorFlow customer data and physical security.

These requirements protect:

  • Your customers' buildings
  • People's physical safety
  • Your liability exposure
  • Compliance obligations
  • Everyone's reputation

If you want to integrate with a system that protects your customers as seriously as you do, join us.

On this page