krooj

Same!

Oh wow - seeing my own work in the wild is ... wild. I implemented the RAS end of this for Atlassian. There will certainly be iterations around this flow - CIMD, better tenancy support, etc., but all the folks involved in delivering this at Anthropic, Okta, and here at Atlassian were fantastic.

My man, all these fuckers use the same parasitic management consultancies. That's why all this shit looks the same.

Interesting - I wonder if this isn't a case of theft on a refresh token that was minted by a non-confidential 3LO flow w/PKCE. That would explain how a leaked refresh token could then be used to obtain access, but does the Vercel A/S not implement any refresh token reuse detection? i.e.: you see the same R/T more than once, you nuke the entire session b/c it's assumed the R/T was compromised.

Question - from the perspective of the actual silicon, are these NPUs just another form of SIMD? If so, that's laughable sleight of hand and the circuits will be relegated to some mothball footnote in the same manner as AVX512, etc.

To be fair, SIMD made a massive difference for early multimedia PCs for things like music playback, gaming, and composited UIs.

The comment in lines 163 - 172 make some claims that are outright false and/or highly A/S dependent, to the point where I question the validity of this post entirely. While it's possible that an A/S can be pseudo-generated based on lots of training data, each implementation makes very specific design choices: i.e.: Auth0's A/S allows for a notion of "leeway" within the scope of refresh token grant flows to account for network conditions, but other A/S implementations may be far more strict in this regard.

My point being: assuming you have RFCs (which leave A LOT to the imagination) and some OSS implementations to train on, each implementation usually has too many highly specific choices made to safely assume an LLM would be able to cobble something together without an amount of oversight effort approaching simply writing the damned thing yourself.

This is one of those cases where I would hope that extremely strong federalism is exercised from Ottawa: essentially, Alberta could be dissolved, stripped of its provincial status and relegated to a territory. From that point, allow for further subdivision to the various First Nations people, allowing reformation into other territories or offer provincial status. The rest of it could be federally administered - see how they like that.

As much as it pains me to say it, Canada's diversity is also it's weakness, and there needs to be precedent - perhaps not as severe as in the US - that you do NOT leave the dominion.

Yep - I remember the CCAT from 4th grade that resulted in my being placed into a different class for 5th. AFAIK, we were given this test "cold" (no prep) and I remember it being timed.

> In short, Open ID Connect is quite accurately described as an Authentication standard. But OAuth 2.0 has little to do with Authorization. It allows clients to specify the "scope" parameter, but does not determine how scopes are parsed, when user and client are permitted to request or grant a certain scope and what kind of access control model (RBAC, ABAC, PBAC, etc.) is used. That's ok, since it leaves the implementers with a lot of flexibility, but it clearly means OAuth 2.0 is not an authorization standard. It only concerns itself with requesting authorization in unstructured form[3].

This misses the mark - scopes are abstractions for capabilities granted to the authorized bearer (client) of the issued access token. These capabilities are granted by the resource owner, let's say, a human principal, in the case of the authorization_code grant flow, in the form of a prompt for consent. The defined capabilities/scopes are specifically ambiguous as to how they would/should align with finer-grained runtime authorization checks (RBAC, etc), since it's entirely out of the purview of the standard and would infringe on underlying product decisions that may have been established decades prior. Moreover, scopes are overloaded in the OAuth2.0/OIDC ecosystem: some trigger certain authorization server behaviours (refresh token, OIDC, etc), whereas others are concerned with the protected resource.

It's worth noting that the ambiguity around scopes and fine-grained runtime access permissions is an industry unto itself :)

RFC 9396 is interesting, but naive, and for a couple of reasons: 1) it assumes that information would like to be placed on the front-channel; 2) does not scale in JWT-based token systems without introducing heavier back-channel state.

I personally do not view OIDC as an authentication standard - at least not a very good one - since all it can prove is that the principal was valid within a few milliseconds of the iat on that id_token. The recipient cannot and should not take receipt of this token as true proof of authentication, especially when we consider that the authorization server delegates authentication to a separate system. The true gap that OIDC fills is the omission of principal identification from the original OAuth2.0 specification. Prior to OIDC, many authorization servers would issue principal information as part of their response to a token introspection endpoint.

> The industry predominately rewards writing code, not designing software.

The sad part of this is that code is absolutely a side-effect of design and conception: without a reason and reasonable approach, code shouldn't exist. I really think that the relative austerity happening in industry right now will shine a light on poor design: if your solution to solving poorly understood spaces was to add yet another layer of indirection in the form of a new "microservice" as the problem space changed over time, it's probably more likely that there was an inherent poor underlying understanding of the domain and lack of planning extensibility in anticipation. Essentially, code (bodies) and compute aren't as "cheap" as they were when money was free, so front-loading intelligent design and actually thinking about your space and it's use-cases becomes more and more important.

Linus always has a great way of summarizing what others might be thinking (nebulously). What's being said in the article is really mirrored in the lost art of DDD, and when I say "lost" I mean that most developers I encounter these days are far more concerned with algorithms and shuttling JSON around than figuring out the domain they're working within and modelling entities and interactions. In modern, AWS-based, designs, this looks like a bunch of poorly reasoned GSIs in DDB, anemic objects, and script-like "service" layers that end up being hack upon hack. Maybe there was an implicit acknowledgement that the domain's context would be well defined enough within the boundaries of a service? A poor assumption, if you ask me.

I don't know where our industry lost design rigor, but it happened; was it in the schools, the interviewing pipeline, lowering of the bar, or all of the above?

Weird - this is the first place I saw the "internet" on display as a kid. Shame to see it close in such an unceremonious way.

You'd be surprised at how little cloud vendors give a shit about security internally. Story time: I recently went ahead and implemented key rotation for one of our authz services, since it had none, and was reprimanded for "not implementing it like Google". Fun fact: Google's jwks.json endpoint claims to be "certs" from the path (https://www.googleapis.com/oauth2/v3/certs). They are not certs - there is no X.509 wrapper, no stated expiration, no trust hierarchy. Clients are effectively blind when performing token validation with this endpoint, and it's really shitty.

Other nonsense I've seen: leaking internally signed tokens for external use (front-channel), JWTs being validated without a kid claim in the header - so there's some sketchy coupling going on, skipping audience validation, etc...

Not much surprises me anymore when it comes to this kinda stuff - internally, I suspect most cloud providers operate like "feature factories" and security is treated as a CYA/least-concern thing. Try pushing for proper authz infrastructure inside your company and see what kinda support you'll get.

You really think that's anti-social behaviour? It's a matter of practicality, my delicate flower.

This is basically how I handle it, and we live in the neighborhood mentioned by this article. The disability claim is largely a straw man argument: I've never seen someone in a wheelchair try to navigate SF streets - they're far, far too hilly and para-transport exists. This whole thing comes down to SFMTA being a bunch of crash-grabbing motherfuckers. The amount of revenue the city takes in through ticketing is outrageous, to the point that it's less and less about bylaw enforcement and more about making money.

I think last year my total $-amount for SFMTA tickets came to ~$1300? Still cheaper than paying for a garage or wasting my time trying to find street parking.

More on context here: the sidewalks of the outer sunset and outer richmond are extremely wide, to the point were you could easily parallel park 1.5 cars right on the sidewalk, so it's trivial to park a car such that it being partially in the driveway will leave more than enough space for anyone to pass.

I also have the same mutation, as does my wife. From what I've been told by various hematologists, vascular surgeons, and interventional radiologists, it's a very weak clotting disorder, but you do have to keep an eye on certain environmental factors: smoking, hydration, movement, and trauma/surgery. To put it another way, FVL is fairly benign until you're already way into Virchow's danger done, and at that point it's gonna work against you. When it comes to VTE in the presence of ONLY FVL, I would shoot serious side-eye at a doc that chalked it up to the mutation - there's usually something else going on.

I'll echo this - I have had two left leg DVTs, spaced about 7 years apart, and after the second event, really started diving into medical publications - surgical journals, medical textbooks, clinical trials - as a means to better understand the condition, it's pathology, etc. I ultimately submitted to testing and discovered a congenital stenosis of the left iliac vein with heavy retroperitoneal collateralization that necessitated a stent to keep that iliac vein open.

I also had a quick look into the social media (primarily reddit) aspect of these vascular conditions, and it's a pile of dogshit. Most of these patient communities bill themselves as "support groups", but there's never any real discussion on meaningful research, drug, or device advancements. They places serve primarily as "pity pits" for chronic moaners and scammers selling alternative medicine.

They absolutely do not and also introduce a significant amount of overhead with respect to key/certificate management.

No, there's no explanation.

Agree - you only need to look at things like the hybrid flows to see where things fall apart: why would you issue an id_token that contains user information to a client which hasn't yet fully authenticated itself via a code-to-token exchange with passing it's client_id + secret? If you look at certain implementations, such as Auth0, you'll find that they actually POST that token back at the redirect_uri, since, a) it's at least registered against the client; b) it's not subject to capture as easily. The spec says NOTHING about protecting this info, though.

Yup - OIDC can be boiled down to:

1. The OG OAuth2 spec never said anything about identifying principals 2. OIDC mandated an id_token to avoid the hit of POSTing the access token to an introspection endpoint 3. The shape of the id_token is a JWT

This doc is junk, btw - it's suggesting the client use the id_token for the purposes of authentication? I wouldn't trust that token beyond some basics, unless you have very strong controls over the authorization server and IdP to ensure things like email verification are propagated correctly.

1000x this - each and every CAIM has their own "interpretation" of what the various constructs actually mean in the various RFCs and it leads to a lot of hodge-podge integrations that organizations outgrow. Things like Okta and Auth0 might seem shiny and easy on the face of it, and they are for very small startups, but quickly devolve into dogshit as you scale.

I feel as though this is a consequence of organizations not really understanding how complex the space truly is. The way I've watched OAuth2 + OIDC get adopted in various companies was never from a security-first perspective; rather, it's always sold as a "feature": login with x, etc. Even when there are moves to make flows more secure - PKCE, for example - you end up playing a game of "whack-a-mole" with various platforms doing shitty things in terms of cookie sharing, redirect handling, and the like. The fundamentals of 3-legged OAuth2 are sound and there's tons of prior art (CAS comes to mind), but the OpenID Foundation should be tarred and feathered for the shitty way they market and sold OIDC.

If you do this and I am the one interviewing you, I will fail you. I will figure out what you actually do/don't know and if you are incapable of performing at the applied level, I will fail you.

Our family went through the same thing with a budget Celeron "MDG" computer running Windows 98. Awful. Keep in mind that, like you, I had previously used a IIsi and an LC630, so I figured... 300MHz, must be amazing?!?

At some point later, my high school had surplus Powermac 7500/100s that were gifted from Nortel and I managed to snag one, paired it with a USR 56k external modem and it was a million times better than that Celeron econobox.

This article is not as impressive as one might imagine - the exploit appears to use the implicit grant flow, which is officially deprecated and should be replaced by the authorization_code + PKCE flow.

The important thing with PKCE is that it's not completely secure, either. A malicious actor can create an app that uses your client_id and its own code_challenge and verifier. In the event that there are any issues with redirect jacking, such as may be the case with custom schemes on mobile, you're hosed. The only way around this is to use intents (on Android) and OS pinning in the client configuration of your authorization server.

No. This is wrong. Implicit is deprecated in favor of authorization_code + PKCE

This is what the client_credentials grant flow is intended for. If you're using any interactive grant flows to secure S2S communications, you're doing it wrong.

Their 3D reconstruction viewer has some neat examples - there's a carbon fiber bicycle saddle where you can absolutely see voids in the layup process and step through the sagittal slices to see the propagation characteristics.