You should use the subject identifiers, not the usernames. You store a mapping of provider & subject to internal users yourself.
But this has been a problem in the past where people would hijack the email and create a new Google account to sign in with Google with.
Similarly, when someone deletes their account with a provider, someone else can re-register it and your hash will end up the same. The subject identifiers should be unique according to the spec.
Ah yeah but I wanted my platform to provide universal OAuth with any platform (that my app developer user trusts) as OAuth provider. If you rely entirely on subject identifiers; in theory, it gives one platform (OAuth provider) the ability to hijack any account belonging to users authenticating via a different platform; e.g. one platform could fake the subject identifiers of their own platform/provider to intentionally make them match that of target accounts from a different platform/provider.
Now, I realize that this would require a large-scale conspiracy by the company/platform to execute but I don't want to trust one platform with access to accounts coming from a different platform. I don't want any possible edge cases. I wanted to fully isolate them. If one platform was compromised; that would be bad news for a subset of users, but not all users.
If the maker of an application wants to trust some obscure platform as their OAuth provider; they're welcome to. In fact, I allow people running their own KeyCloak instances as provider to do their own OAuth so it's actually a realistic scenario.
This is why I used the hash approach; I have full control over the username on my platform.
[EDIT] I forgot to mention I incorporate the issuer's sub in addition to their username to produce a username with a hash which I use as my username. The key point I wanted to get across here is don't trust one provider with accounts created via a different provider.
Proprietary techniques like this are usually a good indication you’re missing something. In this case it sounds like you are missing appropriate validation of the issuer and/or token itself.
I want to support OAuth2, not OpenID so I don't rely on a JWT; I call the issuer's endpoint directly from my backend using their official domain name over HTTPS. I use the sub field to avoid re-allocation of usernames/emails but my point is that I don't trust it on its own; I couple it with the provider ID.
To make it universal, I had to keep complexity minimal and focus on the most supported protocol which is plain OAuth2.
If we end up with metric tons of unused HBM memory lying around, I'm sure that someone will design a general purpose computer using them, or design a HBM-to-DDR interface.
Probably AI in the sense of what Google DeepMind has been up to with the protein folding and other biological simulations, instead of the LLM variant of AI.
2) Why aren't the military craft listening to the local flight channel? Aren't you supposed to monitor local traffic? Especially when flying without a transponder? It's not like you can't listen to multiple channels at the same time!
Military aircraft mostly do not have civilian VHF radio, only military UHF radio. They can only communicate with civilian aircraft by using civilian ATC as a go-between, and only if the civilian ATC is equipped with military UHF radio. In the US, this military equipment is standard at civilian ATC sites for this reason.
Why don't they have at least a receive-only radio? I can understand if they're averse to someone keying up and accidentally broadcasting Secret Military Stuff on the civilian frequency, but a an air-band capable VHF receiver is less than $100 as a consumer buying single units. Surely the MIC could find a way to add one for just $10k as cheap insurance against losing a $5 million plane in a tragic and avoidable accident?
reply