[daczka92]

Pisze w #angular gui do pewnego serwisu. Autoryzacja jest po oauth i troche nie czaje idei refresh token. Zwykly token ma ogrwniczony czas zycia i jak sie skonczy to moge uzyc refresh token do tego aby dostac nowy. Jaki jest wiec sens tego refresh skoro on ma nieograniczony czas życia. Ktos go moze sobie przechwycic i ma na zawsze jakby login i haslo użytkownika. Wystarczy ze go odpowiednio wysle i ma normalny token. Malo tego, klikniecie logout wcale nie oznacza ze sie wylogowalismy. Wystarczy i tak podac ten refresh i bez podawania hasla i loginu uzyskujemy dostep.
Jaka jest dobra praktyka? Moge wysylas POSTa z unieważnieniem go po wylogowaniu. Czy mam czyscic to ciasteczko z tokenami po wylogowaniu? Czy jakos sprawdzać bezczynnosc i wymuszac to ww. wylogowanie razem z czyszczeniem?
#webdev #webdesign #programowanie i #python z #django bo serwis z api i oauth jest djangowski

[Michuy]

@daczka92:

Refresh tokens must be stored securely by an application because they essentially allow a user to remain authenticated forever.

They are usually subject to strict storage requirements to ensure they are not leaked. Nevertheless, they can be blacklisted by the authorization server.

Refresh Tokens are long-lived. This means when a client gets one from a server, this token must be stored securely to keep it from being used by

[Michuy]

Może mógłbyś go przy wylogowaniu blacklistować na serwerze

[daczka92]

@Michuy: jest taka opcja zeby wysylac postem aby dany refresh token stawal sie niewazny. Cos jak to blacklistowanie. Ale nadal nie mam gdzie tego refresh przechowywac bo aplikacja to sam angular. To ma byc tylko nakladka bez wchodzenia teraz w jakis backend. A tutaj pisza ze nie mozna go przechowywac w przegladarce... Musze cos innego wykombinowac.

[Zaszczyk]

@daczka92: może w Twoim przypadku lepiej się sprawdzi implicit grant?

[Bruno_]

@Michuy milion userow, kazdy sie wyloguje raz dziennie, gdzie bys to wszystko trzymal?

[Michuy]

@Bruno_: nie używałbym refresh token w takim przypadku ¯\_(ツ)_/¯