Thread 106285512

I don't see the point of having both. Why can't we just have a long lived access token and be done with it
>muh compromised
if they managed to get your access token then they probably have your refresh token too

noa sex

>>106285512 (OP)
Because getting another fresh token requires providing credentials, which you shouldn't be storing after the initial handshake

>>106285620
but why not just let access token obtain a new one. the more i think about the more i think refresh token are unnecessary bloat.

> which you shouldn't be storing
then how do you know the refresh token? you need to store it somewhere

noa to meet yaa

>>106285691
what's the point of a short lived token that can refresh itself indefinitely?

>>106285875
that's exactly what i want to know. that's why this access/refresh token just seems pointless. you're suppose to store both but you can keep getting new token as long as you have refresh token. just only have a single long lived token at this point.

>>106285512 (OP)
my guess is that they can have independent expirations and you can also immediately invalidate a refresh token upon use (if you tie it to a session persisted somewhere else), while in the way you're describing, after the token expires the user is left with noa-ccess to the application until they log in again

>>106285605
FPBP

>>106285945
those are some nice thighs

>>106285994
indeed, my friend

>>106285512 (OP)
*smooch*

Sorry sarr, it's just not possible to generate tokens on the client side without sharing secrets more than once. Technology is just not there yet....
% oathtool --totp=SHA512 --time-step-size=3600 --digits=8 "$(base32 <<"For once, OP wasn't a retarded nigger faggot")"
31675918

>>106285605
fpbp
/thread

I explicitly use the plain non-refresh token in one of my application where it suffices to limit the blast radius in case I fuck up and get breached.
Using too many priviledges and hoarding too much data is a big common thread in many of the amateur projects