I landed everything so far to master. The new behavior in master should be:
I stumbled across what appears to be a very mild security issue in JIRA that impacts this flow. I've reported it to Atlassian's bug bounty program here (this link may or may not be visible to anyone else):
Sat, Feb 22
This change sequence is almost ready to remove readers and writers to accountID, but there's still a unique <accountType, accountDomain, accountID> key on the table. Removing accountID writers completely will mean that the second user to link an account of a particular type (say, an Asana account) will run into a unique key error (since they'll write a second "Asana" account with the same empty accountID as the first "Asana" account).
Fri, Feb 21
Thu, Feb 20
These callers use accountId:
I think the patch above is a piece of the solution here, but makes behavior worse for some installs: installs with a version of JIRA which returns both key and accountId will have worse behavior under the patch than without it (since it will break all the existing account links immediately). It also doesn't smoothly migrate these installs, even though it's theoretically easy/desirable to do that.
Wed, Feb 19
If you're feeling ambitious, here's a likely patch:
When a user logs in to "new" JIRA, we also can't easily tell if they have an existing account link based on the presence of an accountId.
Tue, Feb 4
The actual replacement is Authorization: token <token>, I believe:
Thu, Jan 30
I think D20905 is as good as we're going to get.
Jan 15 2020
These changes seem to have stuck.
Nov 13 2019
On Ubuntu 14, the messages are a little less helpful:
Nov 11 2019
Nov 8 2019
This may also impact the Doorkeeper integration, which reads "id" fields from a few calls.
Oct 28 2019
Agreed that supporting YubiKey OTP is pointless - it's impractical and basically a dead legacy feature at this point. WebAuthn has emerged as the de-facto standard for hardware tokens.