Choose an Authentication Provider: Startup Scorecard
Compare managed authentication, libraries, and custom systems with a practical scorecard for account operations, portability, evidence, and support.
Retrospective series date: 2026-10-13. This label describes the series order, not a historical publication.
Choose an authentication provider by the work your team must operate after launch. A login demonstration does not show recovery, revocation, migration, or support limits.
Use this scorecard to compare a library, managed service, and custom implementation. Apply the same evidence standard to each.
Start with your actual alternatives
List the options your team would realistically use. Include the existing system if replacing it creates migration work.
A library may fit a team that wants control and can operate the surrounding services. A managed provider may fit a team that wants to reduce that operating burden.
Custom implementation can meet unusual needs, but your team owns the protocol and lifecycle work.
Read the build-versus-buy guide for a wider cost discussion.
Define requirements before scoring
Record your user types, organization model, sign-in methods, environments, deployment needs, and support expectations.
Separate launch requirements from later features. An attractive roadmap should not receive the same score as demonstrated current behavior.
Assign weights that reflect your product. Do not reuse another company's priorities without review.
Copy this evidence scorecard
Download the provider scorecard. Record evidence before assigning scores.
| Criterion | Weight | Required evidence |
|---|---|---|
| Integration fit | Set weight | Completed journey in your framework |
| Account operations | Set weight | Recovery and user-management demonstration |
| Authorization boundary | Set weight | Correct token and organization model |
| Revocation | Set weight | Observed behavior and documented limits |
| Data handling | Set weight | Region, processors, retention, and access details |
| Portability | Set weight | Export format and protocol support |
| Operating cost | Set weight | Current quote and workload assumptions |
| Support | Set weight | Confirmed support route and terms |
Use a score from zero to three. Zero means evidence is missing. One means a documented claim exists. Two means a demonstration exists. Three means your team verified the requirement.
A zero is a research task. It does not automatically mean the provider lacks the feature.
Use a transparent calculation
For each requirement, multiply its weight by the evidence score. Add the results.
This is a decision aid, not an objective industry ranking. Keep the evidence beside the score so another reviewer can challenge it.
Set mandatory requirements separately. A high total must not hide a failed requirement that blocks launch.
Test recovery and revocation yourself
Run an account-recovery journey. Revoke a session and try the protected request again.
Ask how existing access tokens behave after revocation. Check cache delays and session boundaries.
If a provider describes immediate removal, ask what exactly becomes unusable and when.
Check migration before committing
Confirm export access, linked identity behavior, password-hash compatibility where relevant, and user identifier stability.
Do not assume that standards support makes every migration automatic. User records, credentials, and sessions can require separate plans.
Document the exit path before the system becomes critical.
Compare cost with operating responsibility
Use the same assumptions for active users, authentication methods, message delivery, environments, and support.
Add the team's expected maintenance work. Avoid invented savings or a claim that one provider is always cheapest.
Record the quote date. Recheck pricing before the final decision.
Contact the NamoID team
Include NamoID in the scorecard when its current customer-authentication scope fits your needs. Ask the team to show evidence for your requirements.
Contact our engineers in Slack with your stack and scorecard. We can help you evaluate the integration and explain current limits.
Choose another approach when it better meets a mandatory requirement.