Agree this stuck out to me - I think a lot of confusion stems from how to handle refresh tokens - the oauth spec I feel is responsible by the confusion of how it calls apps “clients” and how flimsy it is about implementation (should/shall/must). If you are keeping refresh token locally on the user agent, you really urgently need to provide the user session management tools to revoke those things, and you need to be doing more advanced threat/abuse detection of their usage.
Most people should probably follow the pathways laid out by IdentityServer4 and oidc-client, even if not not using .NET Core (you could absolutely deploy it standalone). Lots of sane defaults, even for refresh tokens and revocations and other difficult specs to understand. It’s well maintained and well thought out.
Comments
Agree this stuck out to me - I think a lot of confusion stems from how to handle refresh tokens - the oauth spec I feel is responsible by the confusion of how it calls apps “clients” and how flimsy it is about implementation (should/shall/must). If you are keeping refresh token locally on the user agent, you really urgently need to provide the user session management tools to revoke those things, and you need to be doing more advanced threat/abuse detection of their usage.
Most people should probably follow the pathways laid out by IdentityServer4 and oidc-client, even if not not using .NET Core (you could absolutely deploy it standalone). Lots of sane defaults, even for refresh tokens and revocations and other difficult specs to understand. It’s well maintained and well thought out.