maxwellg

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.

Well, that’s a terrifying honeypot at best…

We can have both. The resources aren't coming from the same bucket. Public transportation must be built by the local government, and is subject to that local government's ability to execute. In contrast, Self driving cars are largely siphoning resources from for-profit companies.

I live in the west side of San Francisco, and we may get a subway station by 2050 if we're exceptionally lucky. I'd rather have self-driving cars this decade, please.

It is viable. Think of workload identity federation as the mechanism for the client to get an bearer token initially, and DPoP as the mechanism for the client to present the access token to a resource server. Each DPoP proof is entirely self-contained, so resource servers don't need to manage any additional state. The only new state is the (usually ephemeral) private key held by the client:

1. Client generates a private/public keypair and uses it to generate DPoP Proofs - JWTs containing the entire public key embedded as a JWK within

2. Client presents credentials (WIF, client creds, auth code, etc.) to the Authorization Server along with a DPoP Proof

3. Authorization Server validates DPoP Proof and adds a claim to the access token containing the thumbprint - the SHA-256 hash - of the public JWK.

4. Resource Servers will now see the thumbprint claim and now know the access token needs to be presented with a fresh DPoP proof.

5. Clients generate fresh DPoP proofs and send them along with the access token

There are lots of additional details around nonces, timestamps, per-request binding, etc. but DPoP can be rolled out to any HTTP system that speaks Bearer token already.

> There are lighter weight options that do basic stuff like transaction management and binding result sets to object properties that are much less of a PITA than ORMs.

Query builders like these are my personal favorite from a productivity perspective! The point of a query builder is to dynamically build SQL statements that have many subtle variations (do we want to filter by EmailID or PhoneID here? What about a subquery? Did the caller want all results, or just results where $field=X?). They're basically one level above string templating for SQL generation, and often have niceties around ser/de and transaction management as you mentioned.

Because they are primarily about query generation, it feels _very_ natural to pop off the hood and write raw queries directly when necessary. You can usually use the transaction management and ser/de parts with raw queries, too.

My personal favorite in this field is knex.js.

> If the client wants to detect custom API gateways, it can say so plainly. It can send an explicit telemetry field with documentation. It can make the policy visible. It can put the behavior in release notes.

This seems like a very naive response. If clients send explicit telemetry fields to the gateway, a malicious gateway can trivially strip or modify the field to conform to what normal traffic looks like. The steganography cat-and-mouse game is valuable because it is much harder for a gateway to continuously reverse engineer all the fingerprinting mechanisms used. Sure, some malicious gateways will be able to stay on top of things, but not all - and not always.

Huge congrats to the folks behind this at Okta, A\, Microsoft, Figma, Linear, etc...

For the MCP nay-sayers - don't worry there's something here for you too :)

This is powered by a new token format called an ID-JAG - https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a... - and isn't MCP specific at all. ID-JAGs can be used for safe and secure data sharing anywhere where data is shared between applications that use the same SSO provider.

In regular OAuth, end users consent to share their data with applications individually. This makes sense for consumer usecases, where the end users own their data. But it doesn't make sense for many business usecases, where the business is the entity that should control data sharing and access, not the end user. As an employee at Acme, I shouldn't decide to link my Acme Google Drive data to Claude or ChatGPT, that should be the decision of my IT Department.

Enterprise-Managed OAuth, or Cross App Access (XAA), brings this IT-Admin centrally controlled sharing model into the OAuth framework so it works with the existing ecosystem.

There's also a great UX benefit from moving data sharing consent management from employees to IT Admins - it means that employees don't need to sit through a bunch of OAuth flows to link their accounts together. Their IT Admin has already set up all the sharing controls. Everything plugs in together and should Just Work from day one. Think joining a new company on the first day and your Slack is already linked to your Zoom, your Drive, your Calendar, etc...

Pre-GenAI I wrote a new interview question for a role on our team. As far as I know, the question was never made public. The interview required implementing a pretty basic CSS-in-JS utility in vanilla javascript. We instructed the candidate read the MDN documentation for the CSSStyleSheet interface, and then gave them a public API to implement. Passing implementations usually consisted of a ~10 line for loop, and was really just a test of whether a developer pick up and work with new libraries on the fly. Still, the interview probably had a 30% pass rate.

On a lark, I asked ChatGPT to complete the interview question in late 2022. I would have hired ChatGPT back then based on its first response! It was easily in the 90th percentile of responses I have seen.

Wouldn't a browser that doesn't execute JS also not execute the browser fingerprinting code in the first place?

Is your agent harness dropping the entire MCP server tool description output directly into the context window? Is your agent harness always addig MCP servers to the context even when they are not being used?

MCP is a wire format protocol between clients and servers. What ends up inside the context window is the agent builder's decision.

Mikey might have a profit incentive at play, but let's be abundantly clear - the drivers he is catching are frequently flagrantly breaking the law and endangering both themselves and the people around them. I have a very hard time feeling sympathy for those who are unable or unwilling to operate a car safely on public roads.

> The only issue it solves is if you want to bring your own tools to an existing chatbot.

That's a phenomenally important problem to solve for Anthropic, OpenAI, Google, and anyone else who wants to build generalized chatbots or assistants for mass consumer adoption. As well as any existing company or brand that owns data assets and wants to participate as an MCP Server. It's a chatbot app store standard. That's a huge market.

I've also had drivers do 50+ in residential areas, run red lights, play on their phones, cut off pedestrians in crosswalks, and once even park in a handicap spot at a gas station to buy cigs with me left in the back seat. If I was guaranteed a driver that could obey the traffic laws, I'd be happy to continue taking Ubers. That hasn't been the case.

The initial remote MCP specification was pretty painful, but the June spec and the upcoming November spec are much more workable - MCP auth is (mostly) just OAuth now. MCP Clients are OAuth clients and can be granted access tokens and managed just like any other 3rd party app integration.

I'd love to hear more about the specific issues you're running into with the new version of the spec. (disclaimer - I work at an auth company! email in bio if you wanna chat)

Ironic that DHH is politically active enough that it affects his day to day activities and public perception of his company - kind of the exact opposite of his own policy he expects his employees to abide by.

I’ve bought several of the WAOAW sleep masks as well. They’re great for the price point - I have a nasty habit of forgetting them in hotel beds though. I tend to go through one every few years or so. My wife enjoys hers as well.

Has anyone bought the third brand to round out the discussion?

The innocuous https://grants.github.com/apply URL goes to a completely different site. Sneaky sneaky.

I should caveat this by saying this is certainly not 9/9/6, yeesh. Weekdays are fuzzy but never 12 hour days. Do you count going to a meetup after hours as work? A dinner with a prospect? Early coffee with a coworker? Saturdays or Sundays are maybe two or three hours at the most.

Of course we are! This year has been the most exciting (and fun!) of my career in the Bay. There is so much to do and so much going on. Things that were impossible a year ago suddenly feel imminent. Nobody is forcing (or really even asking) me to work on the weekends but if I have an interesting idea bouncing around in my brain I'm not going to wait to Monday to play around with it.

Cloudflare is only the first to market with a solution. If this proposal catches on every WAF vendor under the sun will have it implemented before the next sales cycle. Enforcement of this standard will be commoditized down to nothing.

It cracks me up to no end how the dev tools are much better MCP clients than the web chatbots. Claude Code is so _so_ much better at MCP than Claude Web, which has issues with managing DCR client state, is comparatively terrible at surfacing debug information up, doesn't let regular users see under the hood at how tools are described or called, etc.

Using Claude Code or your IDE of choice to book a hotel is a fun unintended side effect of this.

I would also recommend the OAuth 2.1 IETF draft as a precursor to the BCP: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-...

Although it isn't a published RFC yet, it intends to replace several sometimes-conflicting previous RFCs + the BCP with a single document.

Refresh tokens are only really required if a client is accessing an API on behalf of a user. The refresh token tracks the specific user grant, and there needs to be one refresh token per user of the client.

If a client is accessing an API on behalf of itself (which is a more natural fit for an API Key replacement) then we can use client_credentials with either client secret authentication or JWT bearer authentication instead.

Many "softer" forms of SSO have trickled down too. Google + Microsoft OAuth are ubiquitous today without any upchage. OAuth from a Google Workspace account managed by an IT admin has many of the same security guarantees as SAML or OIDC from a Google Workspace account, at least for a small player. There are some sketches like https://easie.dev/ that explore this further.

For extra security, an intermediary can set Content Security Policy (CSP) headers that instruct browsers to only connect to certain domains. CSP headers aren't a total solution, but they're a good tool in the toolkit for redundancy against exfiltration.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

SSO chaining is super common in large corporate environments. Different orgs might have their own SSO IDP, acquisitions often bring their own, etc. Once a provider is in use, it is quite difficult to tear out later while keeping everyone in their proper accounts in all the apps that tie in. Many apps are really bad at SSO migrations, or deduplicating multiple SSO identities to a single user account.

This is conceptually extremely similar to the Web Push API: https://web.dev/articles/push-notifications-web-push-protoco...

You'd need something at the browser/UA level to unsubscribe or to make the subscription exist for only a single message. Bad content publishers have taught us to never allow Web Push notifications since they always get inundated with marketing and other nonsense - being able to bake protections against that into the spec could be interesting.

I dream of a low-milage early 2000s Taco with aftermarket Carplay

Installing a dependency for myself is just and a little harder the first time. Asking every developer who will ever consume my service over CURL to install a dependency is absolutely an ongoing burden.