Over the last few months, I invested pretty heavily into setting up SSO for my self-hosted stack. However, some apps gate SSO behind paid plans, meaning accounts and thus MFA need to be set up outside of the IdP. This leaves me with a weird mix of accounts handled by the IdP and those that I need to track manually.

There wasn't really a good way to track this mixture, especially once you add multiple MFA devices and sensitive data like recovery codes, because the IdP has one half and the password manager has the other (+ maybe it's the second factor itself).

That's why I built RecoveryCodes. It allows me to track all my accounts, see which MFA devices I've enrolled (I usually enrol 2 per account, in case one is lost) and also gives me a place to store recovery codes (instead of copy pasting them into a random .txt file).

Obviously I'm n=1, so I'm interested in hearing from slightly larger companies how you're dealing with this mix? Spreadsheets maybe, or are most of the accounts covered by IdPs and the rest don't really matter?

Comments URL: https://news.ycombinator.com/item?id=49376741

Points: 2

# Comments: 1

It's my understnading that setting up cookies to work on mobile is quite painful, though it depends on the platform. IIRC iOS has gotten better at it with a shared cookie storage, but Android requests are still stateless by default, so you basically have to manually wire up a cookie jar and carry it around everywhere you go, so to speak.

Attributes like SameSite also behave differently, and WebViews don't share the same cookie jar as native requests as far as I understand.

Bottom line is that maybe "Cookies also don't work on mobile" is a bit of a wrong statement, but it's certainly more of a hassle and a path lined with more footguns than just wiring up an OAuth provider and sending access and refresh tokens back and forth using Authorization headers. The great thing with Session cookies on desktop is simplicity, which you sort of lack on mobile.

But they're still the superior choice for authN on the web, because if you want to, you CAN configure cookies to be secure. Yes, attackers can ride the session, but it's dependent on the user being on the tab and you being able to consistently execute JS. Client-side compromise (ie attacker controls the entire browser) is not feasible to defend against anyway.

The main issue with JWT+localStorage is you can actually execute one-off JS, exfiltrate the token and come back later. I've _never_ seen a well-executed JWT+localStorage implementation in 10 or so years, because teams inevitably realise they can't reliably revoke sessions (another advantage of cookies) and then start giving out long-lived access tokens but adding them to the database. Or some variation of that.

Turns out it's a lot easier to build on top of a common framework than do everything from scratch.

On the other hand, minified code is literally published by the company. Everyone can see it and do with it as they please. So handing that over to an AI to un-minify is not really your problem, since you're not the developer working on the tool internally.

Good luck!

Over the years, I've built quite a few OpenAPI specs that'd get neglected over time and where the endpoints would eventually drift away from the spec.

I wanted to build something super lightweight that I could drop in during development to double check that my endpoints still match the spec as expected.

SpecGate is a lightweight proxy that checks API responses against the given OpenAPI spec. It'll tell you if there's an undocumented endpoint or if the response doesn't match the spec. I managed to catch about 10 issues with one of my more recent specs as soon as I started using it.

It's possible to run this in production as well, but it currently only logs to stdout/stderr, so keep that in mind if you decide to run it in production.

Would love to hear your feedback on this tool.

Comments URL: https://news.ycombinator.com/item?id=44953604

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=44822593

Points: 3

# Comments: 5