#GWGSo, I built a simple refresh token implementation, but the refresh tokens aren't tied to the access tokens, so the only way a refresh token gets removed is if it expires or is redeemed. Seems wrong
KartikPrabhu and jamietanna joined the channel
#jamietannaGWG I don't have them tied currently (nor have revocation) but I'm planning on having a "consent ID" that'll be in both tokens, and be what can be used to revoke both tokens by the user
#Loqijamietanna: GWG left you a message 5 hours, 36 minutes ago: When you have a few minutes, would you be able to act as a sounding board for refresh token implementation?
#GWGjamietanna: My access tokens have a generated uuid I put in a few versions ago I could link to
#GWGI have revokation for access, not refresh tokens
#GWGAuthorization codes, access tokens, and refresh tokens are all stored the same way, using the same class with only different locations passed.
#jamietannaYeah so I guess you'd probably want i.e. the UUID that's in the access token to be linked to the authorization code, and refresh token too
#GWGSo, if I redeem a refresh token, I should invalidate the old refresh token, which is fine, but should I also invalidate the access tokens associated with that refresh token, or just let them expire naturally?
shoesNsocks1 and jamietanna1 joined the channel
#jamietanna1The user / app has said revoke, so generally all access should be revoked ASAP
#jamietanna1No an access token should still be valid
#aaronpki would say it makes sense to revoke the access token immediately too. since only one client should be using the access token, if that client uses the refresh token then it should never be using the previous access token again
#aaronpkthe only exception is clients that are made up of multiple parts (threads, processes, etc) where they may not be able to coordinate between all the parts