To add my anecdote, while the Codex subscription appears to get you much fewer tokens as measured by cost, I find the amount of actual useful work that can be done by both subs to be about equal. Codex seems much less prone to burning millions of tokens just reading the codebase and doing nothing useful. That also makes it much quicker. Plus it actually does what I tell it with few mistakes first time, so less rework needed.

The Claude TUI is just so much better though so I'm hoping Opus 5.5 is actually good and not just benchmaxxed.

SAML sucks, but it still has a bunch of features for its specific narrow enterprise SSO use-case that OIDC lacks - most notably IdP-initiated flow. OIDC is a constellation of specs with inconsistent support across products, whereas the commonly-implemented subset of SAML is more-or-less stable in its mediocrity.

OIDC will eventually displace SAML, but if you're selling to enterprises you should really support both. Both will pale compared to the amount of time you spend dealing with SCIM inconsistencies between IdPs anyway.

OIDC doesn't support IDP initiated flows for a reason - they're vulnerable to a class of attacks known as Login CSRF. An attacker can trick a victim into submitting an IdP-initiated authentication response linked to the attacker's account/session into the victim's browser profile on the SP. Think - Eve tricks Bob into signing in to Eve's PayPal account instead of Bob's. Bob, none the wiser, links his bank account. Eve now has access to Bob's funds.

IdPs that need to support an "IdP-initiated" user experience (like a portal or dashboard where users click an app icon) should instead have that icon link to a specific landing page on the SP that safely kicks off a standard, SP-initiated OIDC flow. IdP -> (SP -> IdP -> SP). Look at Okta's "Initiate Login URI" for an example of this.

SAML implementations can protect against this by turning IdP-initiated requests into an SP-initiated request. On the SP-initiated responses, there is an `InResponseTo` field that can be validated (or `RelayState` can be made to work).

The OIDC specification is pretty hand-wavy about how to prevent this attack as well. So don't assume all OIDC implementations do.

OIDC spec has a limited third-party initiated flow[1] that redirects to the RP (equivalent to SP in SAML), which then starts a regular OIDC flow that is indistinguishable from an RP-initiated flow.

This flow is safe against CSRF, since no authentication data is carried together with the flow. The only other safety issue I can see is using target_link_uri for CSF. The spec clearly mentions that this URL has to be filtered or ignored by the RP.

Instead of treating the (horrible) technical implementation as a feature, it addresses the real user-facing feature: I want to be able to click on a link on my IdP dashboard and be redirected to the app. The login would still be seamless, since you already have an SSO session active with the IdP.

[1] https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...

I feel like there is an easy solution to login csrf with IdP initiated flows. The SP just gives a pop up saying - you are logging into X as user Y. Continue?

The has been proven again and again to not work. See for example HTTPS certificate warnings for which now there is a standard to ask browsers to not show a popup just saying "The server might not be the correct one. Continue?"

It's an easy solution, but it doesn't work at all.

I don't really think that is comparable.

For starters, users generally do not understand what a cert validation error means. They do understand what it means to browse to a website.

The cert validation error is in the way of the user's intended action. This popup would not be.

Fundamentally such a pop up is not a security warning. It does not indicate that something is unsafe. That makes a world of difference.

I think a better comparison would be when you exit an app, and the app prompts you if you want to save. That has generally worked well.

What is prventing OIDC-based IdP from initiating login? You just need to know the login URI:

https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...

Does Tailscale support SAML? If not: why would any other enterprise product need to? Tailscale is like the sine qua non of modern enterprise products, and I believe it's OIDC-only.

I don't believe it's plausible for any non-specialist firm to implement SAML without grave vulnerabilities. I'm not sure I've ever seen it done well. It's been a minute since I've looked (I haven't consulted in several years, but, more importantly: most firms avoid SAML now), but I'm guessing that assertion still holds.

> Tailscale is like the sine qua non of modern enterprise products, and I believe it's OIDC-only.

I think you're drastically overstating Tailscale's share and ubiquity in the market. Maybe it's heavily represented in tech companies or those in The Valley but among rank and file normal companies not dominated by developers, they've never heard of Tailscale

I think you're wrong about this, that basically every F500 with an access VPN setup has heard of Tailscale, and further, despite their penetration being much bigger than "tech companies in the valley", my point was that Tailscale is a modern business that exists to make (at this point) large amounts of money, and they're not doing SAML.

(It is good that they're not doing SAML, because SAML is the worst security specification ever written, and very few organizations have ever implemented it safely).

And I think you're wrong about this too.

You're overestimating the importance of Tailscale, underestimating the importance of SAML to enterprises and completely skipping over the fact that the customer base that Tailscale has restricted itself to, probably doesn't use SAML to begin with.

Here, I'll share you my thoughts on Tailscale:

I don't use Tailscale. I don't care about Tailscale. I don't know what Tailscale is and I don't really care to know, but I know what SAML is and I know that I will keep using SAML for the foreseeable future, and I know I won't be using Tailscale.

"sine qua non" is hubris.

Agreed.

Pretty much every large enterprise (inc. half a dozen non-tech F500s) I've seen in the past 5 years has used either GlobalProtect or AnyConnect. Slightly further down the scale, you start to see some Prisma, Fortinet, or F5 as well. All of them support SAML, and market it as being a key feature.

Personally, I'd love to see Tailscale being deployed more widely, but I've only ever seen it deployed by tech companies.

There are a lot of smaller providers that will eschew some features, require a fairly limited integration surface (was the case with a lot of things with Slack integration before Teams' COVID explosion, for instance) to keep their support and development costs down

The best estimates I could find have TS at a 1-2% market share. And that was my point: You suggested "well if Tailscale can get away with not supporting SAML, anyone can!" and I think that's wrong. 98% of the market already is buying Tailscale's competitors, they can hardly do worse

I'm sure they can juice that a good deal more, but eventually they'll have to start picking off features that they have been avoiding to this point. Will that be SAML? Maybe not, most companies are on Entra ID which supports OIDC. The real tell will be when Tailscale either goes public or sells to private equity. When their backs are to the wall and they need to squeeze out another percent or two in growth and they have a big customer that must have SAML, then they'll do it

One of the issues I've run into with Tailscale OIDC is that an email domain must be mapped to a single tailnet. So if my IdP has consultants or if my domain contains multiple businesses with different tailnets, I need to do some domain mapping in my IdP and train users to login with that special non-email address.

This isn't strictly a limitation of OIDC, but I do see this issue more often with OIDC implementations. With IdP-initiated flows, the app doesn't need to know who's in my IdP ahead of time.

When we started C1.ai - 2020 - as someone who worked previously at Okta - I made a decision to only implement OIDC. (see article for all of the reasons). We were worried in the first 2 years, that some big enterprise would force us to implement SAML.

But it turns out, all the major IDPs support OIDC now. It's a non-issue.

You can use Keycloak as a SAML/OIDC -adapter.

> Both will pale compared to the amount of time you spend dealing with SCIM inconsistencies between IdPs anyway.

I think that's the real problem. Just tying up things with custom, system dependent configurations would probably be more predictable. Most people are probably happy to get the happy path running.

Eh, many of us do what I think you mean by "IdP-initiated flow"s with JWT. It's not OAuth exactly, but it's a thing.

I was prescribed Xanax for a bit and it gave me the absolute worst sleep paralysis imaginable, with nested false awakenings.

Nested false awakenings are the worst. Now I have a phrase to use for when that happened to me.

I dreamt that I was attacked and killed by a monster. Getting killed in a dream makes one wake up immediately, lol. I was hanging out with a friend of mine and telling him about the dream and as soon as I told him what happened he turned into a monster and killed me.

I was driving down the road with my friend Lloyd who was a passenger beside me in the car and telling him about this crazy dream. As soon as I mentioned the monster killing me, he turned into a monster and killed me - while I was driving my stinking car! Then I woke up and I was like "am I fucking really awake now?" I was.

ugh, I would get those as a kid. I've never heard the term 'nested false awakening' applied to them, but I like that. I'm glad I don't get them anymore.. the feeling of wondering if it is a dream or not and feeling like you are locked onto a roller coaster you can't get off of. Luckily in my experience once I actually woke up I would know for sure that it was real. I think it would mess with your psyche if you couldn't tell or convince yourself you weren't in another nested dream.

I thought this was universal. It's pretty easy to trigger for me, even quite abstract geometric shapes that look a bit like something falling from a height can trigger it.

I do not have this, but at this point I couldn't say if it's you folks or me who are "odd".

If places cease to be interesting, people will stop visiting them.

That means either AI will become interesting, or people will figure out how to stop slop ruining their places.

Either of those options might bring their own problems, but the sloppification of the internet is not a stable equilibrium.

The logical answer is to send what you would have put into AI.

However, terse lists of bullets without any padding or phatic expressions are considered rude. Perhaps previously a long message indicated you'd put time and thought into it.

Maybe AI will invert the social signalling, and make conciseness polite. As it should be.

I like attribution in principle, but I'd rather it linked to an open format stored in/with the repository rather than their website.

Simple enough to script someth to do just that.

could ask claude to do that ;P

Irrespective of how it all turns out, I'm personally incredibly excited to be alive during it. In many ways, it is the ultimate milestone.

We'll probably see the explanation of the Fermi paradox.

But then it's better to just not have a gateway switch models at all.

Just have the harness able to choose which model its sub-agents use, then tell it how to split up tasks and which models to use when doing so.

That is another way to do. Or we can automatically figure out which models the subagents should be using for you. And update them as new models come out and the work your subagents do changes. More than one way to skin a cat.

This does make sense. I generally only switch between models in pi when creating a new session. And it is apparent from the promt if this just a "how to see open ports on linux" or "make a concrete plan for feature X"

Clothes too. If you're cold, why not just move to a tropical country where you can be naked, as nature intended?