Episode 099: 03‐27‐2025 New JWT Tokens for RP Acct Mgt - GluuFederation/identerati-office-hours GitHub Wiki
Title: OpenID Provider Commands: New JWT Tokens for RP Acct Mgt
-
Host: Mike Schwartz, Founder/CEO Gluu
-
Dick Hardt, Founder/CEO Hellō, Previous guest on Episode 5
-
Guest: Karl McGuinness, Identerati at large - Previous guest on Episode 66
Description
"OpenID Provider Commands" is a new proposed protocol via Dick Hardt and Karl McGuinness which introduces a mechanism for delivering backchannel "command tokens" (a JWT) that allows an OpenID Provider (OP) to send the following messages to an OpenID Relying Party (RP):
- 🔑 Activate an account
- 🔄 Maintain an account
- ⏸️ Suspend an account
- 🔓 Reactivate an account
- 📦 Archive an account
- ♻️ Restore an account
- ❌ Delete an account
- 🚫 Unauthorize an account
In this episode we'll hear from the authors why they think this new protocol is needed, and why their solution is the right design for the Internet.
Homework
- Here is a link to a very early draft
Takeaways
-
⚡ There are a large swath of B2B apps that support social login, but not a whole lot more. This spec will set the bar for what features an RP can support to be a good federated RP.
-
⚡ The OpenID Provider COMMANDS -- doesn't just "notify" RPs. This implies more urgency is needed by the RP to comply with the action, and models current enterprise worklows for RP management.
-
⚡ The spec addresses both Account and Tenant commands. There is no "tenant" concept in OpenID Connect at the moment. But in practice, IDPs like Google and Auth0 with a single identity domain need some kind of organization identfier, like "o" in inetOrgPerson :-)
-
⚡ Server Sent Events (defined by the HTML Living Standard) are used to stream large results from the RP to the OP. For example, if audit_accounts returns millions of accounts, you'd need some kind of paged results--SSE is used as a short-lived streaming session for this purpose.
-
⚡ The use of JWTs for "commands" supports the need for Token Based Access Control. Each command is an "action". The principal is the OP. The resource is the account or tenant in question. The RP needs to validate this new kind of token (JWT Command Token) and make a decision if it should obey the command.
-
⚡ Also addressed in this spec are "groups"--how does the OP convey which accounts should have certain privileges in the RP. This is important to audit entitlements. Join us at IIW for a deeper dive on this.