|
|
|
|
|
by Jach
5071 days ago
|
|
> With very little effort, pretty much anything can be called OAuth 2.0 compliant. This was both a sigh of relief but also slightly horrifying when I was working on an oauth2 server in Node. It encourages a lazy "implement the parts we care about and that are required, and take shortcuts for unspecified things." I thought the separation of access tokens and refresh tokens was wrong because once you're just giving the client an encrypted string to avoid certain DB lookups later you can put whatever data you want in it (the spec doesn't care) including managing refreshes, revokes, etc. I like the idea of expiring tokens of course, but it would simplify the client significantly to just replace the currently used token with a new token issued by the server if one is returned. I recall the 'standard' flow is "request with access token, fail, request new access token with refresh token if you have one, maybe succeed, maybe get a new refresh token, if succeed request with new access token". Having the access token manage the data to refresh itself is simpler. I'd agree it's bad that token security is reduced to cookie security by default, really the whole rant is spot-on. |
|