OID-See v1.1.0: External Identity Posture, iOS Support, and New Auth Methods

This is a personal blog and all content herein is my own opinion and not that of my employer.

OID-See v1.1.0 is out

v1.0.1 tightened the scoring.

v1.1.0 expands what OID-See can actually see.

This is the biggest release since the initial drop: a new external identity posture surface, a fully rearchitected browser engine, iOS support, cross-tenant filter presets, and the first community-contributed feature. A lot happened.

Release: https://github.com/OID-See/OID-See/releases/tag/v1.1.0

External identity posture

The headline feature of v1.1.0 is external identity posture analysis.

OID-See now parses JWT tokens to extract tenant-level identity posture signals. These signals are surfaced directly in the Dashboard UI and included in the HTML report output.

This gives you a new angle on tenant risk that sits above individual app scoring: how is the tenant configured for external and federated identities, and what does that mean for trust decisions across your app estate.

The feature ships with a full unit test suite covering the posture collection logic.

Web Worker architecture

The entire processing pipeline has been moved off the main thread and into a Web Worker.

This was not a cosmetic refactor. The old architecture processed large JSON inputs synchronously on the main thread, which caused UI freezes on large tenants and complete failures on mobile. The input panel has been removed as part of this change.

The practical results:

• The dashboard remains responsive during scan processing regardless of tenant size
• Graph conversion no longer happens on import — the graph view is now lazy-loaded
• Memory use is substantially reduced for large datasets
• The --generate-report crash caused by incorrect traversal of tierBreakdown in extract_metrics has been fixed

iOS support

The universal graph view unblocks OID-See on iOS Safari.

The previous graph rendering approach hit a hard wall on iOS: chunked async processing and memory constraints made the graph view unusable. v1.1.0 fixes this with chunked async processing and memory optimisations specifically targeting the Safari engine.

OID-See on an iPhone is not a primary use case, but it should work now. More importantly, this fix improves reliability for anyone on constrained hardware or network-restricted environments who needed a lighter rendering path.

Cross-tenant filter presets

The graph view ships with eight built-in filter presets for cross-tenant analysis.

Rather than manually constructing filter combinations each time, you can now select from presets designed around common investigation patterns. This is particularly useful when comparing app risk posture across multiple tenants or when triaging a specific risk category quickly.

New scanner authentication methods

Contributed by @SuryenduB — the first external contributor to OID-See.

The scanner now supports three authentication methods via the --auth-method flag:

• interactive-browser — opens a browser prompt for interactive login
• azure-cli — uses an existing Azure CLI session
• default — the original behaviour, unchanged

This matters for pipeline and automation scenarios where device code flow is not appropriate, and for environments where Azure CLI credentials are already in place.

The contribution has been fully documented across all release docs and the README.

UI fix: score badge overlap

A layout bug caused score badges to overlap long app names in the top risky nodes panel. This has been fixed. The panel now handles long node names correctly at all viewport sizes.

What didn’t change

• The data model and JSON schema — no breaking changes
• The risk scoring philosophy from v1.0.1
• The local-only, no-SaaS, no-consent architecture

OID-See still runs entirely in your browser. Nothing is sent anywhere.

First community contribution

It is worth calling out explicitly: this release includes the first feature contributed by someone outside the project.

@SuryenduB added the new auth methods. That is meaningful. The tool is useful enough that people want to improve it, and that is the best signal a small open source project can get.

If you have been thinking about contributing — this is what the entry point looks like.

Feedback

If you run v1.1.0 against a real tenant and find something that looks wrong, open an issue or start a discussion on GitHub.

The tool gets better every time someone uses it against something it didn’t expect.