If you look at it through the eyes of just Starlink though it makes a lot of sense. The new v3 sats do solve a lot of the problems with Starlink in more (suburban) areas with much more capacity per sat.
In a happy path if Starship works and v3 works, each Starship launch would launch ~60Tbit/sec of downstream capacity and ~10Tbit/sec of upstream (ideal world figures yada yada).
With falcon 9 and v2 mini, each launch provides ~2Tbit/sec of downstream and ~0.2Tbit/sec of upstream.
So roughly 30x the downstream and 50x the upstream.
The upstream is probably the critical part to improve as well for congestion (usually upstream gets saturated before downstream in most retail ISP configs, on asymmetrical technologies like DOCSIS and causes terrible user experience).
So Spaceship could be ~40x the cost per launch of Falcon 9 and it would still make sense financially. I assume it won't be anywhere near that. And this doesn't take into account how much further Starlink will be on all the other competitors that are trying to spring up.
I think if you ignore everything else and just focus on Starlink (which has the potential to be a $100bn/yr business easily) it is worth them rolling the dice. Whether it actually works or not is interesting to discuss - but figures like $500m/launch is really pocket change for the scale/potential scale that Starlink operates in.
Unfortunately this is unlikely to be successful. There is just no way you can run a reliable overnight passenger service on the intercity rail infrastructure of the US.
The track is mostly single track and heavily used by freight (where a few hours delay isn't the end of the world). Multi hour delays are extremely common and even with it being overnight, if you set off at say 11pm and aim to arrive at 8am, a 3 hour delay could see you arriving at 11am and your VIP passengers missing all their business meetings. They won't return!
FWIW I don't think Europe's push to overnight rail trains will be very effective either. It doesn't work well with overnight maintenance windows, and the yield per train is extremely low (100 passengers in 50 'rooms' vs 1000 normal seating passengers dictate a 10x ticket price). Also is extremely complex in Europe with many different signalling/communication systems, traction systems, etc.
Agree with all of this. The ridership might be there but I doubt the business case is - and this is true in Europe as well. As far as I can tell sleeper services generally are not money-makers, and are subsidized by regular passenger service.
Which may be a desirable policy outcome for state rail agencies - but this is a private venture!
I think cost is an under-appreciated aspect of this. You're carrying 5-10x fewer passengers per-train, at greater cost (the cost of turning over a stateroom is many times higher than cleaning a coach seat, along with linens, food, etc.), on very expensive custom equipment that isn't suitable for other uses.
There seem to be two "major" (really heavy scare quotes here) players in the US private sleeper service scene. Dreamstar IMO is the more promising of the two (heavy caveat that this is relative to each other, not absolute odds) by realizing the only way to make the economics work is the ability to charge $$$$$ for tickets.
The other (Lunatrain) IMO is just out to lunch, with a claimed focus on affordability. None of the above leads to affordable tickets.
As somebody who is working on exactly this problem, I’d say the problem can be solved technically if one can get a high density of passengers, while providing privacy and comfort.
Most of the sleeper startups basically just work with renderings, we work with iterating on full sized mock ups. We did ergonomics/market testing with hundreds of test users. We have evidence that with the right cabin technology, you can be profitable, even produce a margin, and significantly disrupt air travel.
Have taken this in Europe, was really nice, and I consider this quite competitive with inter-European airlines:
It saves a lot of time, because you can use central train stations instead of transfering to/from the airport, and you depart late in the evening (get full use out of the departure day) and arrive somewhat early in the morning (don't lose much of that day, either).
So it does not have to be cheaper than an inland flight, it just has to be competitive with flight + 2x transfer + hotel, and while it might be slightly less comfortabel than a hotel room, you avoid airport transfer and -security, which is nice.
Yes but it's clearly not competitive because it has such a tiny marketshare and runs at a giant loss. And that's in Europe with exceptional infrastructure compared to the US (a lot of 4 track lines, with everything at least double track, allowing freight to get out the way).
Northeast Regional (including Acela) is also very successful. But you may not consider that long distance. In fact, I thought most of the Amtrak's profits came from that. There are a couple other city pairs that do reasonably but, yes, mostly not.
I took the Acela NY to Boston this year, and won't ever do it again. What was the time difference from the non-high speed supposed to be? I think it's a 40 minute difference or something.
We had multiple delays along our route and the 4 hour trip turned into almost 7.
Yeah, there are various regions but I don't consider it long distance until it has a sleeper (which I don't believe Acela has).
Pacific Surfliner is also very popular and close to profitable.
To be fair, Amtrak could make some or more of its routes profitable depending on how it allocates expenses - after all, they get hired to run some of the commuter rails, too.
No, Acela doesn't really make sense for Boston to DC travelers in general although I've done it when time wasn't really critical. Yeah Pacific SW combinations can work--again if time isn't of the essence. Have also done other relatively short routes like Raleigh to Charlotte.
LA → San Diego is competitive or even beats car trips (during rush hour).
It’s always my great sadness that they didn't make that the first high-speed rail segment, heck a few billion dollars on double track and other improvements would have cut an hour off that time. I don’t even know if LA union Station is straight though yet.
I would be surprised if it has even 1% marketshare on the routes they are on (vs driving, coach, day trains and flights.
For example; in the UK on London -> Edinburgh, Caledonian Sleeper has on average 250 passengers per day (but this is the entire route - not just london to edinburgh). Given there is roughly ~2tph throughout the day for about 16 hours a day, each with ~1000 seats (with very high load factors), that's about 30,000 passengers/day on the "day" train. Probably roughly that again flying. Plus driving and coaches and it is absolutely tiny.
I almost reflexively avoid both intra-European air travel and renting a car when I can. But if you're being cost-conscious, it's hard to avoid the European budget airlines compared to other alternatives a lot of the time, especially if you're traveling between major cities.
Like, where? I lived in four EU countries and travelled to most of member states. I only heard of Austrian sleeper and some luxury Swiss expertise. Never heard anyone taking a sleeper in the modern times. Moscow-Paris train used to be a thing, but that’s in the past.
The fact that _you_ have not heard of it does not mean that it does not exist. The Austrian ÖBB has created a massive network over the last few years, including some innovative new rolling stock with sleeping cap capsules. Many classic routes within larger countries still exist, like the multiple routes in the UK, France and Sweden. There are new private startups like European Sleeper that operate an Antwerp - Prague sleeper
There's the London to Edinburgh Caledonian Express which I took and I took a sleeper from Brussels to Koln to Vienna? Koln was a stopover. Forget where the sleeper segment was. But I'll admit it was situations where neither time nor money were critical and were intermixed with business trips.
In the UK at least the grocery stores are completely empty. I've barely seen anyone in them. Bizarrely they are shutting loads down in London but opening new ones at the same time. Absolutely no idea what the strategy is, they must be throwing out the majority of the fresh food stock they have.
The problem I've got with JWTs is that actually you can rarely (never, really in my experience?) assume anything in the JWT apart from user id are valid for a long period of time.
For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got whatever else was in the claim there quickly.
Same with roles; if you downgrade an admin user to a lower 'class' of user then you don't want it to take minutes to take effect.
So then all you are left with is a unified client id format, which is somewhat useful, but not really the 'promise' of JWTs (I feel?).
Active user logouts, deletions, permission changes are rare, so the size of revocations lists is extremely small compared to number of tokens in existence.
You can keep revocations in a very fast lookup system (eg broadcasts + in-memory store), combined with reasonably short token renewals, like 5-60 minutes.
Massively cuts down the number of token validity checks, and makes the system tolerant to downtimes of the auth system. That's less relevant for basic apps where the auth data is in the same DB as all the other data, but that is rarely the case in larger systems.
And when building distributed systems a bunch of systems don't really care about those changes immediately anyway so the propagation delay is acceptable, or you can push the burden of refreshing to the client for privilege expansion cases, etc.
This makes it sound like you've only worked in an extremely narrow domain.
It's not rare, it happens constantly in enterprise software, project managemment software, anything where you have collaboration.
What is so frustrating about tech like JWTs is that it fits the fairly rare, high profile, websites like Reddit, netflix, etc. but doesn't fit ANYTHING else.
Everyone else wants immediate revocation of rights, not waiting for a token to expire.
And yet we all have to suffer this subpar tech because someone wrote a blog post about it and a bunch of moronic software "architects" made it the only option. If you don't JWT somehow you're doing it wrong, even though it should in fact be an extremely niche way of doing Auth at scale.
Simple cookie based tokens were and still are a much better choice for many applications.
The size of the revocation list is irrelevant. As soon as you have to do a call to get the revocation list you might as well just include the rest of it in the call as well.
It’s important to consider that JWT is a series of specs and folks can choose to use any of them to suit their needs.
In fact, it can be used to create simple tokens—even if you store them in a database in a traditional authentication sense.
But it is also helpful to be able to use OIDC, for example, with continuous delivery workflows to authenticate code for deployment. These use JWT and it works quite well I think.
Note: technically JWT is only one of the specs so it’s not exactly correct how I’m referring to it, but I think of them collectively as JWT. :)
> What is so frustrating about tech like JWTs is that it fits the fairly rare, high profile, websites like Reddit, netflix, etc. but doesn't fit ANYTHING else.
This is only conceivably true if your ability to design services only goes as far as reusing reddit-like usecases for everything and anything.
But everyone else is not incumbered by that limitation.
> Everyone else wants immediate revocation of rights, not waiting for a token to expire.
Where exactly does a JWT prevent you from rejecting revoked tokens? I mean, JWTs support short-lived tokens, jti denylists, single-user tokens with nonces, etc. Why are you blaming JWTs for problems you're creating to yourself.
Can you tell me of any instance where someone's auth needed to be revoked within 5 minutes and a delay was not acceptable? I think it's more of an imaginary 'five nines' engineering thing than real life.
Firstly I don't think most people who use JWTs use 5 min refreshes. But even assuming that - any collaboration software. Imagine you invite a user by mistake to an internal wiki, you don't really want them looking at the content for 5 minutes. Much better to be able to revoke instantly.
Then you have anything that handles financial data. If you're a bank and you get a call that you have a fraudster taking over an account; you want to be able to revoke that straight away. Waiting another 5 minutes could mean many thousands more in losses (simplified example, but you hopefully get my drift), which arguably the bank may be liable for by the regulator.
Also many other "UX" problems, you also don't want roles to be out of sync for 5 minutes. Imagine you are collaborating on a web app and you need to give a colleague write access to the system for an urgent deadline. She's sitting next to you and you have to wait 5 minutes (or do a forced login/logout) before you get access, even after refreshing the page.
Finally it's really far from ideal to be using 5 min refreshes. For idle users with a tab open you will have people constantly pinging the backend all the time to get a refresh. Imagine some sort of IOT use case where you have thousands of devices on very bandwidth limited wide area networks.
Furthermore - it's a total mess on mobile apps. Imagine you have an app (say a food delivery app) that is powered by push notifications for delivery status. If you've got a 5 min token and you push down an update via push notifications telling it to get new data from a HTTP endpoint to update a widget, your token will almost certainly be expired by the time the delivery is on the way. You then need to do a background token refresh which may or may not be possible on the OS in question.
You don't tell them they are fired and then revoke access immediately. Either access is already revoked or they are given a reasonable time to close out (you have end of day before we revoke access, we will revoke access after this meeting etc). Either way a JWT expiring every second versus 5 minutes doe not change things.
I'm trying to be sensible here not dream up straw man scenarios of which there are many.
Some auth servers implement it. Keycloak does[0]. Auth0 doesn't as far as I can tell[1]. FusionAuth (my employer) has had it listed as a possible feature for years[2] but it never has had the community feedback to bubble it up to the top of our todo list.
I don't think status lists solve the requirement for near-realtime revocations.
The statuslist itself has a TTL and does not get re-loaded until that TTL expires. This is practically similar to the common practice of having a stateful refresh token and a stateless access token. The statuslist "ttl" claim is equivalent to the "exp" claim of the access token in that regard, and it comes with the same tradeoffs. You can have a lower TTL for statuslist, but that comes at the cost of higher frequency of high-latency network calls due to cache misses.
The classic solution to avoid this (in the common case where you can fit the entire revocation list in memory) is to have a push-based or pub/sub-based mechanism for propagating revocations to token verifiers.
If you read the draft, the TTL is clearly specified as optional.
> (...) and does not get re-loaded until that TTL expires.
That is false. The draft clearly states that the optional TTL is intended to "specify the maximum amount of time, in seconds, that the Status List Token can be cached by a consumer before a fresh copy SHOULD be retrieved."
> You can have a lower TTL for statuslist, but that comes at the cost of higher frequency of high-latency network calls due to cache misses.
The concept of a TTL specifies the staleness limit, and anyone can refresh the cache at a fraction of the TTL. In fact, some cache revalidation strategies trigger refreshes at random moments well within the TTL.
There is also a practical limit to how frequently you refresh a token revocation list. Some organizations have a 5-10min tolerance period for basic, genera-purpose access tokens, and fall back to shorter-lived and even one-time access tokens for privileged operations. So if you have privileged operations being allowed when using long-lived tokens, your problem is not the revocation list.
In that case, when and how would you reload the statuslist?
Again, it doesn't matter if TTL and caching is optional, what matters is that this specification has NOTHING to do with a pub/sub-based or push-based mechanism as described by GGGP.
This draft specifies a list that can be cached and/or refreshed periodically or on demand. This means that there will always be some specified refresh frequency and you cannot have near-real-time refreshes.
> There is also a practical limit to how frequently you refresh a token revocation list. Some organizations have a 5-10min tolerance period for basic, genera-purpose access tokens, and fall back to shorter-lived and even one-time access tokens for privileged operations. So if you have privileged operations being allowed when using long-lived tokens, your problem is not the revocation list.
That's totally cool. Some organizations are obviously happy with delayed revocations for non-sensitive operations, which they could easily achieve them with stateful refresh tokens, without the added complexity of revocation lists. Stateful and revokable refresh tokens are already supported by many OAuth 2.0 implementations such as Keycloak and Auth0[1]. All you have to do is to set the access token's TTL to 5-10 minutes and you'll get the same effect as you've described above. The performance characteristics may be worse, but many ap which are happy with delayed revocation are happy with this simple solution.
Unfortunately, there are many products where immediate revocation is required. For instance, administrative dashboards and consoles where most operations are sensitive. You can force token validity check through an API call for all operations, but that makes stateless access tokens useless.
What the original post above proposed is a common pattern[2] that lets you have the performance characteristics (zero extra latency) of stateless tokens together with the security characteristics of a stateful access token (revocation is registered in near-real-time, usually less than 10 seconds). This approach is supported by WSO2[3], for instance. The statuslist spec does nothing to standardize this approach.
> In that case, when and how would you reload the statuslist?
It only depends on your own requirements. You can easily implement pull-based or push-based approaches if they suit your needs. I know some companies enforce a 10min tolerance on revoked access tokens, and yet some resource servers poll them at a much higher frequency.
> Again, it doesn't matter if TTL and caching is optional (...)
I agree, it doesn't. TTL is not relevant at all. If you go for a pull-based approach, you pick the refresh strategy that suits your needs. TTL means nothing if it's longer than your refresh periods.
> This draft specifies a list that can be cached and/or refreshed periodically or on demand. This means that there will always be some specified refresh frequency and you cannot have near-real-time refreshes.
Yes. You know what it makes sense for you. It's not for the standard to specify the max frequency. I mean, do you think the spec specify max expiry periods for tokens?
Try to think about the problem. What would you do if the standard somehow specified a TTL and it was greater than your personal needs?
> you want to be able to revoke auth straight away if an account is compromised
It really depends on the system. In my experience, there are tons of apps that want to be able to revoke access but weigh that against transparent re-authentication. OIDC handles both nicely with:
* short access/id token lifetimes (seconds to minutes)
* regular transparent refreshes of those tokens (using a refresh token that is good for days to months)
This flexibility lets developers use the same technology for banks (with a shorter lifetime for both access/id tokens and refresh tokens) and consumer applications (with a short lifetime for access/id tokens and a longer lifetime for refresh tokens).
> For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got whatever else was in the claim there quickly.
FWIW, I built a system previously that got around this "having to check the DB on every access to check for revocations" issue that worked quite well. Two important things to realize:
1. Revocations (or what is usually basically "explicit logout") is actually quite rare in a lot of user application patterns. E.g. for many web apps users very rarely explicitly logout. It's even rarer for mobile apps.
2. You only need to keep around a list of revocations for as long as your token expiry is. For example, if your token expiration is 30 mins, and you expire a user's tokens at noon, by 12:30 PM you can drop that revocation statement, because any tokens affected by that revocation would have expired anyway.
Thus, if you have a relatively short token expiration (say, a half hour), the size of your token expiration list can almost always fit in memory. So what I built:
1. The interface to see if a token has expired is basically "getEarliestTokenIssuedAt(userId: string): Date" - essentially, what is the earliest possible issuance timestamp for a token for a particular user to be considered valid. So, revoking a user's previously issued tokens means just setting this date to Now(), then any token issued before that will be considered invalid.
2. I had a table in postgres that just stored the user ID and earliest valid token date. However, I used postgres' NOTIFY functionality to send a broadcast to all my servers whenever a row was added to this table.
3. My servers then just had what was a local copy of this table, but stored in memory. Again, remember that I could just drop entries that were older than the longest token expiration date, so this could fit in memory.
On the off-chance that somehow the current revocation list couldn't fit in memory, I build something in the system that allowed it to essentially say "memory is full" which would cause it to make a call back to postgres', but again, that situation would naturally clear up after a few minutes if revocations went back down and the token expiration window passed.
This sounds more complicated than it actually was. It has the benefits of:
1. Almost no statefulness, which was great for scalability.
2. Verifying a token could still always be done in memory, at least almost. Over a couple years of running the system I actually never hit a state when the in-memory revocation list got too big.
Just seems like a lot of extra fiddly stuff to go wrong for monolithic apps. I get it if you have went all in on microservices as each "client" request can fan out to hundreds of requests, each requiring an auth check.
But still, I'm not sure that I've seen an auth/roles database that couldn't fit (at least) the important stuff itself in RAM itself fwiw. Even 1TB of RAM is relatively affordable (if you are not on the hyperscalers) and you could fit billions of users in that, which at least in theory means you can just check everything and not have another store to worry about.
> You only need to keep around a list of revocations for as long as your token expiry is. For example, if your token expiration is 30 mins, and you expire a user's tokens at noon, by 12:30 PM you can drop that revocation statement, because any tokens affected by that revocation would have expired anyway.
And this sort of thing is basically what redis is for, right? Spin up a docker container, use it as a simple key value store (really just key store). When someone manually invalidates a token, push it in, with the expiry date is has anyway.
Might not even need to store the token itself just a piece of data that is contained in the claims to say the account is in a good state. Any number of tokens then can be issued and the validation step would ensure the claims is correct.
What you describe sounds like it will make any explicit log out action users do on any device turn into a ”log me out from all devices” action, which was probably not at all the user’s intent unless that is the only explicit option you give them.
A "logout" action from the user should just delete the JWT from the device he is using. Asuming the token wasn't compromised, there is no backend work involved.
Is this as secure as doing a blacklist for non-expired tokens? No, it isn't. It is a sane tradeoff between decent security and implementation complexity.
Terminating sessions on other devices is not possible, but another tradeoff is using a "Logout from all devices" mechanism. In that case you just have a global "token not issue before" field, and when you logout from all devices, set that timestamp to the current time (and all issued tokens will fail authentication).
But again, tradeoff. You individual requirements may vary.
> 1. Almost no statefulness, which was great for scalability.
This is called "eventual consistency", it's probably fine in practice but you still do have a lot of state. Personally, if I have any in-application state at all, I would use a sticky cookie on the LB to send each client to the same instance.
This seems like about the best that can be done (well, you could go full Bloom filter to squeeze that revocation list size down even further), but it does seem vulnerable to DoS: Create 10000 accounts and log them all out at the same time to force the server into the slow PostgreSQL mode.
Any system that allows you to create 10000 accounts is already vulnerable to DoS.
Also, as vintermann suggested, you can use a faster, domain-specific database if you're concerned about this becoming an issue. And sometimes edge cases like this aren't worth considering until you hit them.
Yes but generally magic links are only used for authentication. So if you delete or downgrade the principal whoever uses that magic link to authenticate can only perform the operations that are associated to the principal and the check is performed after the magic link is verified, unless the magic link also used to carry auth claims
Clicking on links in emails is a security risk because they could be spam. I don't do that unless it's the only way to move forward and then I double check the url. Basically I only use it to sign up then never again if possible.
I have a random idea regarding compromised tokens, which may not hold water.
What if you put things like the client's IP address in the token? Then the server can reject (and mark for compromise) as soon as they receive any request from a different ip address?
I realise this will also invalidate people who somehow roam between ip addressses, say DHCP/wireless in a larger building.
Enterprise customers often have split tunnel VPNs or proxies (with PAC configs) where part of the traffic may go through a VPN and another part goes directly. So for example a customer admin might configure an app that does email and webRTC so that the real time traffic (media and the associated signalling) goes directly and the email traffic goes via some TLS intercepting proxy for some compliance reason or DLP. This can result in one application having multiple public IPs for different network requests, even while they are on one internal network (not even jumping between networks like you say). That isnt something that the application author can control, it's the customer admin that decides to do that.
There are two in-use RFCs to make compromised tokens much harder to use by attackers. Neither use IP addresses, but both bind the token to the client using some form of cryptography.
RFC 8705 section 3[0], binds tokens by adding a signature of a client certificate presented to the server doing authentication. Then any server receiving that token can check to see that the client certificate presented is the same (strictly speaking, hashes to the same value). This works great if you have client certs everywhere and can handle provisioning and revoking them.
RFC 9449[1] is a more recent one that uses cryptographic primitives in the client to create proof of private key possessions. From the spec:
> The main data structure introduced by this specification is a DPoP proof JWT that is sent as a header in an HTTP request, as described in detail below. A client uses a DPoP proof JWT to prove the possession of a private key corresponding to a certain public key.
These standards are robust ways to ensure a client presenting a token is the client who obtained it.
Note that both depend on other secrets (client cert, private key) being kept secure.
Yup. I worked for a media company that made IP part of the access token for media playback. An absolute PITA for the mobile app, and made (reliable) background downloads impossible on iOS. A bad idea. They went out of business.
You don't have to check the db every request. Just store a list of revoked tokens in a fast cache, like redis, with ttl longer than the longest token lifetime and reject/force reauth any token that matches
"Bearer" and JWT are orthogonal. Tokens in other format or stateful formats can be bearer tokens, while JWTs can use non-bearer authentication methods. For instance, RFC 9449 (DPoP) describes an authentication method where you have to provide a PoP (based on JWS) in addition to an access token (which may or may not be JWT).
> For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got whatever else was in the claim there quickly.
I fail to see the relevance of your scenarios regarding JWTs. I mean, I get your frustration. However, none of it is related t JWTs. Take a moment to read what you wrote: if your account is compromised, the attacker started abusing credentials the moment he got them. The moment the attacker got a hold of valid credentials is not the moment you discovered the attack, let alone the moment you forced the compromised account to go through a global sign-off. This means that your scenario does not prevent abuse. You are revoking a token when it was already being abused.
Also, as someone who implemented JWT-based access controls in resource servers, checking revocation lists is a basic scenario. It's very often implemented as a very basic and very fast endpoint that provides a list of JWT IDs. The resource server polls this endpoint to check for changes, and checks the list on every call as part of the JWT check. The time window between revoking a token and rejecting said token in a request is dictated by how frequent you poll the endpoint. Do you think, say, 1 second is too long?
> Same with roles; if you downgrade an admin user to a lower 'class' of user then you don't want it to take minutes to take effect.
It's the exact same scenario: you force a client to refresh it's access tokens, and you revoke which tokens were issued. Again, is 1 second too long?
Also, nothing forces you to include roles in a JWT. OAuth2 doesn't. Nothing prevents your resource server from just using the jti to fetch roles from another service. Nevertheless, are you sure that service would be updated as fast or faster than a token revocation?
> So then all you are left with is a unified client id format, which is somewhat useful, but not really the 'promise' of JWTs (I feel?).
OAuth2 is just that. What's wrong with OAuth?
Also, it seems you are completely missing the point of JWTs. Their whole shtick is that they allow resource servers do verify access tokens locally without being forced to consume external services. Token revocation and global sign-offs are often reported as gotchas, but given how infrequent these scenarios take place and how trivial they are to implement (periodically polling an endpoint hardly changes that.
I don't understand why you seem to think JWTs can't be used for authorization, and the fact that you denigrate this as a "puppynoob" approach is telling, but not necessarily in the way you think it is.
Many large systems with millions of users (e.g. Google's Firebase) store user claims in the token, and that can (and is) used to validate permissions.
JWT is basically just a signed JSON container format (JWS) with a couple of standard claims and recommended verification procedures. They can be used as a component of an authorization system but they would just be a small component of that. I think the question should be whether JWT is a good fit to play a part in authorization?
If you just need to tack in a bunch of scopes which are configured per clients and are rarely changed, or if you need to track authentication method and time for sensitive operations ("amr" and "auth_time" claims in OIDC), JWT could probably do the job. But for more fine-grained RBAC (or any user-permission-based scheme), JWT is quite problematic.
For one, you will need to revoke the access token every time permissions change. On certain type of systems this could happen quite often (e.g. every time somebody shares a folder with you), and you don't want to constantly log the user out, so all clients would have to have logic to automatically refresh the access token (with a permission-less refresh token) on revocation.
The other option is pure bloat: The moment you go beyond a simple admin flag or a fixed set of roles, you're already on the expressway to a bloated 10kb token. In every system that support a technically unlimited amount of resources and roles, storing all ACLs in the token gets you very large tokens really fast.
JWT can be used to store permission bits, but didn't it properly is very complex topic and usually works well only as "subsetting of claimed userid permission set" or "short lived token to be passed to third party to perform an action on behalf of".
One can do also quite complex system based on taking multiple claims as a whole plus signature, but that's taste in my experience other than stuffing user info into token
If it’s a major compromise you can simply roll out a new key… invalidating all current JWTs forcing a new login… you could also group signing keys by user type to further minimise the refreshes.
I think this is the biggest alignment problem with LLMs in the short term imo. It is getting scarily good at this.
I recently found a pretty serious security vulnerability in an open source very niche server I sometimes use. This took virtually no effort using LLMs. I'm worried that there is a huge long tail of software out there which wasn't worth finding vulnerabilities in for nefarious means manually but if it was automated could lead to really serious problems.
The (obvious) flipside of this coin is that it allows us to run this adversarially against our own codebases, catching bugs that could otherwise have been found by a researcher, but that we can instead patch proactively.\
I wouldn't (personally) call it an alignment issue, as such.
If attackers can automatically scan code for vulnerabilities, so can defenders. You could make it part of your commit approval process or scan every build or something.
A lot of this code isn't updated though. Think of how many abandoned wordpress plugins there are (for example). So the defenders could, but how do they get that code to fix it?
I agree after time you end up with a steady state but in the short medium term the attackers have a huge advantage.
They've got a lot better if you have access to their 5G Standalone network. But it does require a new SIM card + compatible phone. It's night and day...
I agree with this and matches my thinking (however - the fact that this is even an option is an incredible breakthrough that I did not expect to happen preLLMs - potentially in decades).
I have basically given up on "in IDE" AI for now. I simply have a web interface on my 2nd monitor of whatever the "best" LLM (currently Gemini, was Claude) is and copy paste snippets of code back and forth or ask questions.
This way I have to physically copy and paste everything back - or just redo it "my way", which seems to be enough of an overhead that I have to mentally understand it. When it's in an IDE and I just have to tick accept I just end up getting over eager with it, over accepting things and then wishing I hadn't, and spend more time reverting stuff when the penny drops later this is actually a bad way to do things.
It's really more a UX/psychology problem at the moment. I don't think the 'git diff' view of suggested changes is the right one that many IDEs use for it - I'm psychologically conditioned to review these like pull requests and it seems my critique of these is just not aligned to critiquing LLM code. 99% of PR reviews I do are finding edge cases and clarifying things. They're not looking at very plausible yet subtly completely wrong code (in the most part).
To give a more concrete example; if someone is doing something incredibly wrong in 'human PRs' they will tend to name the variables wrong because they clearly don't understand the concept, at which point the red flag goes off in my head.
In LLM PRs the variables are named often perfectly - but just don't do what they say they will. This means my 'red flag' doesn't fire as quickly.
The reason it's a farce is because most banks are using some off the shelf system from one of the big vendors in the space OR legacy systems, or both. FIS is a good example.
They have basically no real motive to improve anything (the lock in is utterly extreme) and no doubt will charge through the eyeballs for any improvements - especially ones that are regulatory related.
You can see the difference between a legacy bank and some of the neobanks in the UK. It's absolutely night and day when they own their own modern tech stack.
> using some off the shelf system from one of the big vendors
This also gives the bank 'cover' should an exploit be uncovered in "big vendors" system. They (the bank) are safe liability wise (or at least they think they are) because they used "approved vendor Y" for their authentication system.
If they created their own system, then they would be unable to offload the liability onto someone else.
> If they created their own system, then they would be unable to offload the liability onto someone else.
In a sense. The big banks in the US created Zelle with one of the specific outcomes being to offload liability for unauthorized transactions more on to the consumer than themselves.
In a happy path if Starship works and v3 works, each Starship launch would launch ~60Tbit/sec of downstream capacity and ~10Tbit/sec of upstream (ideal world figures yada yada).
With falcon 9 and v2 mini, each launch provides ~2Tbit/sec of downstream and ~0.2Tbit/sec of upstream.
So roughly 30x the downstream and 50x the upstream.
The upstream is probably the critical part to improve as well for congestion (usually upstream gets saturated before downstream in most retail ISP configs, on asymmetrical technologies like DOCSIS and causes terrible user experience).
So Spaceship could be ~40x the cost per launch of Falcon 9 and it would still make sense financially. I assume it won't be anywhere near that. And this doesn't take into account how much further Starlink will be on all the other competitors that are trying to spring up.
I think if you ignore everything else and just focus on Starlink (which has the potential to be a $100bn/yr business easily) it is worth them rolling the dice. Whether it actually works or not is interesting to discuss - but figures like $500m/launch is really pocket change for the scale/potential scale that Starlink operates in.
reply