This has been on my mind for... years and in consideration with how OIDC standardizes ID Tokens, I think this is how it should work:
azp is the authorized party, the app (authorized by the user for some resource)
iss is the issuer of the token (signs with a private key)
aud is the audience which will read and verify the token (to grant access to resources)
sub is the subject, the user (on behalf of which the transaction is taking place)
An azp (browser app) will submit natural user credentials (passphrase, totp, sms otp, etc)
to the iss (api server with private key) and receive comma-delimited subs (pairwise account ids)
for itself as the aud (api server validating keys).
So:
If iss is aud then sub should be a comma delimited list of all account ppids
single-subject keys (email, email_verified) MUST NOT exist on the token
If iss is NOT aud then sub should be a single account ppid
As I've noted in a thousand code comments in a bit bucket somewhere: this is conceptually how Google, Facebook, and every other enterprise system that allows multiple accounts per credential work. Internally you can access all accounts, but externally you only access one account at a time.
I believe the one-token-per-account rule is a good rule and except in the case of initial login (which would otherwise require cookies to keep the state of the multiple accounts), it works well with the code we have already.
This has been on my mind for... years and in consideration with how OIDC standardizes ID Tokens, I think this is how it should work:
azpis the authorized party, the app (authorized by the user for some resource)issis the issuer of the token (signs with a private key)audis the audience which will read and verify the token (to grant access to resources)subis the subject, the user (on behalf of which the transaction is taking place)So:
issisaudthensubshould be a comma delimited list of all account ppidsemail,email_verified) MUST NOT exist on the tokenissis NOTaudthensubshould be a single account ppidAs I've noted in a thousand code comments in a bit bucket somewhere: this is conceptually how Google, Facebook, and every other enterprise system that allows multiple accounts per credential work. Internally you can access all accounts, but externally you only access one account at a time.
I believe the one-token-per-account rule is a good rule and except in the case of initial login (which would otherwise require cookies to keep the state of the multiple accounts), it works well with the code we have already.