apache888 · September 29, 2017 07:54 · Aug 27, 2017 · Aug 27, 2017 · Aug 27, 2017 · Aug 27, 2017
diff --git a/tokens.md b/tokens.md
@@ -48,8 +48,8 @@ __Поскольку токены это не зашифрованная инф
 "refreshToken": "...",
 "expires_in": 1502305985425
 ```
-3. Приложение сохраняет токены и время смерти __access token'а__, используя __access token__ для последующей авторизации запросов
-4. Перед каждым запросом клиент предварительно проверяет время жизни __access token'а__ (из `expires_in`)и если оно истекло клиент использует __refresh token__ чтобы обновить __ОБА__ токена и продолжить использовать новый __access token__
+3. Клиент сохраняет токены и время смерти __access token'а__, используя __access token__ для последующей авторизации запросов
+4. Перед каждым запросом клиент предварительно проверяет время жизни __access token'а__ (из `expires_in`)и если оно истекло  использует __refresh token__ чтобы обновить __ОБА__ токена и продолжает использовать новый __access token__
 
 __Ключевой момент__ что в момент рефреша то есть обновления __access token'a__ обновляются __ОБА__ токена. Но как же __refresh token__ может сам себя обновить, он ведь создается только после успешной аунтефикации ? __refresh token__ в момент рефреша сравнивает себя с тем __refresh token'ом__ который лежит в БД и вслучае успеха, а также если у него не истек срок, система рефрешит токены. __Внимание__ при обновлении __refresh token__ продливается также и его срок жизни.
 

diff --git a/tokens.md b/tokens.md
@@ -95,8 +95,6 @@ __Проблема:__ Поскольку __refresh token__ продлевает
 - https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/
 - https://habrahabr.ru/company/dataart/blog/262817/
 - https://scotch.io/tutorials/authenticate-a-node-js-api-with-json-web-tokens
-
-
 - Заметка базируется на: https://habrahabr.ru/company/Voximplant/blog/323160/
 - https://www.youtube.com/watch?v=Ngh3KZcGNaU
 - https://www.youtube.com/playlist?list=PLvTBThJr861y60LQrUGpJNPu3Nt2EeQsP

diff --git a/tokens.md b/tokens.md
@@ -96,6 +96,7 @@ __Проблема:__ Поскольку __refresh token__ продлевает
 - https://habrahabr.ru/company/dataart/blog/262817/
 - https://scotch.io/tutorials/authenticate-a-node-js-api-with-json-web-tokens
 
+
 - Заметка базируется на: https://habrahabr.ru/company/Voximplant/blog/323160/
 - https://www.youtube.com/watch?v=Ngh3KZcGNaU
 - https://www.youtube.com/playlist?list=PLvTBThJr861y60LQrUGpJNPu3Nt2EeQsP

diff --git a/tokens.md b/tokens.md
@@ -94,8 +94,10 @@ __Проблема:__ Поскольку __refresh token__ продлевает
 - https://auth0.com/blog/ten-things-you-should-know-about-tokens-and-cookies/
 - https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/
 - https://habrahabr.ru/company/dataart/blog/262817/
+- https://scotch.io/tutorials/authenticate-a-node-js-api-with-json-web-tokens
+
 - Заметка базируется на: https://habrahabr.ru/company/Voximplant/blog/323160/
 - https://www.youtube.com/watch?v=Ngh3KZcGNaU
-- https://scotch.io/tutorials/authenticate-a-node-js-api-with-json-web-tokens
+- https://www.youtube.com/playlist?list=PLvTBThJr861y60LQrUGpJNPu3Nt2EeQsP
 
 
diff --git a/tokens.md b/tokens.md
@@ -60,8 +60,8 @@ __Ключевой момент__ что в момент рефреша то е
 ## Схема рефреша токенов:
 1. Клиент проверяет перед запросом не истекло ли время жизни __access token'на__
 2. И если истекло клиент отправляет на `auth/refresh-token` URL __refresh token__
-3. Сервер смотрит в __payload__ __refresh token'a__ берет __user_id__, ищет по БД данного юзера и достает из него __refresh token__
-4. Сравнивает __refresh token__ от клиента с __refresh token'ом__ найденным в БД
+3. Сервер берет __user_id__ из __payload'a__ __refresh token'a__ по нему ищет в БД запись данного юзера и достает из него __refresh token__
+4. Сравнивает __refresh token__ клиента с __refresh token'ом__ найденным в БД
 5. Проверяет валидность и срок действия __refresh token'а__
 6. В случае успеха сервер: 
     1. Пересоздает и записывает __refresh token__ в БД

diff --git a/tokens.md b/tokens.md
@@ -60,7 +60,7 @@ __Ключевой момент__ что в момент рефреша то е
 ## Схема рефреша токенов:
 1. Клиент проверяет перед запросом не истекло ли время жизни __access token'на__
 2. И если истекло клиент отправляет на `auth/refresh-token` URL __refresh token__
-3. Сервер смотрит в __payload__ __refresh token'a__ берет __user_id__, ищет по БД данного юзера и достает из записи найденного юзера __refresh token__
+3. Сервер смотрит в __payload__ __refresh token'a__ берет __user_id__, ищет по БД данного юзера и достает из него __refresh token__
 4. Сравнивает __refresh token__ от клиента с __refresh token'ом__ найденным в БД
 5. Проверяет валидность и срок действия __refresh token'а__
 6. В случае успеха сервер: 

diff --git a/tokens.md b/tokens.md
@@ -40,9 +40,14 @@ __refresh token__ - выдается сервером по результам у
 
 __Поскольку токены это не зашифрованная информация крайне не рекомендуется хранить в них такую информацию как пароли__
 
-## Схема использования токенов:
+## Схема создания/использования токенов:
 1. Пользователь логинится в приложении, передавая логин/пароль на сервер
-2. Сервер проверят подлинность логина/пароля, в случае удачи генерирует и отправляет клиенту два токена(__access, refresh__) и время смерти __access token'а__ (`expires_in` поле, в __unix timestamp__)
+2. Сервер проверят подлинность логина/пароля, в случае удачи генерирует и отправляет клиенту два токена(__access, refresh__) и время смерти __access token'а__ (`expires_in` поле, в __unix timestamp__). Также в __payload__ __refresh token'a__ добавляется __user_id__
+```
+"accessToken": "...",
+"refreshToken": "...",
+"expires_in": 1502305985425
+```
 3. Приложение сохраняет токены и время смерти __access token'а__, используя __access token__ для последующей авторизации запросов
 4. Перед каждым запросом клиент предварительно проверяет время жизни __access token'а__ (из `expires_in`)и если оно истекло клиент использует __refresh token__ чтобы обновить __ОБА__ токена и продолжить использовать новый __access token__
 
@@ -55,8 +60,9 @@ __Ключевой момент__ что в момент рефреша то е
 ## Схема рефреша токенов:
 1. Клиент проверяет перед запросом не истекло ли время жизни __access token'на__
 2. И если истекло клиент отправляет на `auth/refresh-token` URL __refresh token__
-3. Сервер сравнивает __refresh token__ от клиента с __refresh token'ом__ лежащим в БД
-4. Сервер проверяет валидность и срок действия __refresh token'а__
+3. Сервер смотрит в __payload__ __refresh token'a__ берет __user_id__, ищет по БД данного юзера и достает из записи найденного юзера __refresh token__
+4. Сравнивает __refresh token__ от клиента с __refresh token'ом__ найденным в БД
+5. Проверяет валидность и срок действия __refresh token'а__
 6. В случае успеха сервер: 
     1. Пересоздает и записывает __refresh token__ в БД
     2. Создает новый __access token__

diff --git a/tokens.md b/tokens.md
@@ -1,6 +1,6 @@
 # Token-Based Authentication(JWT)
 
-## Предварительные условия:
+## Preconditions:
 В данной заметке рассматривается работа JWT с __симметичным__ алгоритмом шифрования (HS256/HS384/HS512)
 
 ## Основы:

diff --git a/tokens.md b/tokens.md
@@ -1,5 +1,8 @@
 # Token-Based Authentication(JWT)
 
+## Предварительные условия:
+В данной заметке рассматривается работа JWT с __симметичным__ алгоритмом шифрования (HS256/HS384/HS512)
+
 ## Основы:
 
 __Аутентификация(authentication, от греч. αὐθεντικός [authentikos] – реальный, подлинный; от αὐθέντης [authentes] – автор)__ - это процесс проверки учётных данных пользователя (логин/пароль). Проверка подлинности пользователя путём сравнения введённого им пароля с паролем, сохранённым в базе данных пользователей;

diff --git a/tokens.md b/tokens.md
@@ -40,7 +40,7 @@ __Поскольку токены это не зашифрованная инф
 ## Схема использования токенов:
 1. Пользователь логинится в приложении, передавая логин/пароль на сервер
 2. Сервер проверят подлинность логина/пароля, в случае удачи генерирует и отправляет клиенту два токена(__access, refresh__) и время смерти __access token'а__ (`expires_in` поле, в __unix timestamp__)
-3. Приложение сохраняет токены и и время смерти __access token'а__, используя __access token__ для последующей авторизации запросов
+3. Приложение сохраняет токены и время смерти __access token'а__, используя __access token__ для последующей авторизации запросов
 4. Перед каждым запросом клиент предварительно проверяет время жизни __access token'а__ (из `expires_in`)и если оно истекло клиент использует __refresh token__ чтобы обновить __ОБА__ токена и продолжить использовать новый __access token__
 
 __Ключевой момент__ что в момент рефреша то есть обновления __access token'a__ обновляются __ОБА__ токена. Но как же __refresh token__ может сам себя обновить, он ведь создается только после успешной аунтефикации ? __refresh token__ в момент рефреша сравнивает себя с тем __refresh token'ом__ который лежит в БД и вслучае успеха, а также если у него не истек срок, система рефрешит токены. __Внимание__ при обновлении __refresh token__ продливается также и его срок жизни.

diff --git a/tokens.md b/tokens.md
@@ -39,7 +39,7 @@ __Поскольку токены это не зашифрованная инф
 
 ## Схема использования токенов:
 1. Пользователь логинится в приложении, передавая логин/пароль на сервер
-2. Сервер проверят подлинность логина/пароля, в случае удачи генерирует и отправляет клиенту два токена(__access, refresh__) и время смерти __access token'а__ (`expires_in` поле в __unix timestamp__)
+2. Сервер проверят подлинность логина/пароля, в случае удачи генерирует и отправляет клиенту два токена(__access, refresh__) и время смерти __access token'а__ (`expires_in` поле, в __unix timestamp__)
 3. Приложение сохраняет токены и и время смерти __access token'а__, используя __access token__ для последующей авторизации запросов
 4. Перед каждым запросом клиент предварительно проверяет время жизни __access token'а__ (из `expires_in`)и если оно истекло клиент использует __refresh token__ чтобы обновить __ОБА__ токена и продолжить использовать новый __access token__
 

diff --git a/tokens.md b/tokens.md
@@ -18,14 +18,16 @@ __Авторизация(authorization — разрешение, уполном
 
 *Дабы не путатся с понятиями __Authentication/Authorization__ можно использовать псевдонимы __checkPassword/checkAccess__(я так сделал в своей API)*
 
-__JSON Web Token (JWT)__ — содержит три блока, разделенных точками: заголовок, набор полей (claims) и подпись. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Набор полей содержит произвольные пары имя/значения, притом стандарт JWT определяет несколько зарезервированных имен (iss, aud, exp и другие). Подпись может генерироваться при помощи и симметричных алгоритмов шифрования, и асимметричных. Кроме того, существует отдельный стандарт, отписывающий формат зашифрованного JWT-токена.
+__JSON Web Token (JWT)__ — содержит три блока, разделенных точками: заголовок(__header__), набор полей (__payload__) и __сигнатуру__. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Набор полей содержит произвольные пары имя/значения, притом стандарт JWT определяет несколько зарезервированных имен (iss, aud, exp и другие). Сигнатура может генерироваться при помощи и симметричных алгоритмов шифрования, и асимметричных. Кроме того, существует отдельный стандарт, отписывающий формат зашифрованного JWT-токена.
 
 Пример подписанного JWT токена (после декодирования 1 и 2 блоков):
 ```
 { «alg»: «HS256», «typ»: «JWT» }.{ «iss»: «auth.myservice.com», «aud»: «myservice.com», «exp»: «1435937883», «userName»: «John Smith», «userRole»: «Admin» }.S9Zs/8/uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY
 ```
 
-__Токены__ предоставляют собой средство __авторизации__ для каждого запроса от клиента к серверу. Токены генерируются на сервере основываясь на секретном ключе(который хранится на сервере) и __payload'e__. Токен в итоге хранится на клиенте и используется при необходимости __авторизации__ како-го либо запроса. Такое решение отлично подходит при разаработке SPA.
+__Токены__ предоставляют собой средство __авторизации__ для каждого запроса от клиента к серверу. Токены(и соотвественно сигнатура токена) генерируются на сервере основываясь на секретном ключе(который хранится на сервере) и __payload'e__. Токен в итоге хранится на клиенте и используется при необходимости __авторизации__ како-го либо запроса. Такое решение отлично подходит при разаработке SPA.
+
+При попытке хакером подменить данные в __header'ре__ или __payload'е__, токен cтанет не валидным, поскольку сигнатура не будет соответствовать изначальным значениям. А возможность сгенерировать новую сигнатуру у хакера отсутствует, поскольку секретный ключ для зашифровки лежит на сервере.
 
 __access token__ - используется для __авторизации запросов__ и хранения дополнительной информации о пользователе (аля __user_id__, __user_role__ или еще что либо, эту информацию также называет __payload__)
 

diff --git a/tokens.md b/tokens.md
@@ -16,7 +16,7 @@ __Авторизация(authorization — разрешение, уполном
 
 Собственно п.5 и есть процесс __авторизации__.
 
-*Дабы не путатся с понятиями __Authentication/Authorization__ можно использовать псевдонимы __checkPassword/checkRole__(я так сделал в своей API)*
+*Дабы не путатся с понятиями __Authentication/Authorization__ можно использовать псевдонимы __checkPassword/checkAccess__(я так сделал в своей API)*
 
 __JSON Web Token (JWT)__ — содержит три блока, разделенных точками: заголовок, набор полей (claims) и подпись. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Набор полей содержит произвольные пары имя/значения, притом стандарт JWT определяет несколько зарезервированных имен (iss, aud, exp и другие). Подпись может генерироваться при помощи и симметричных алгоритмов шифрования, и асимметричных. Кроме того, существует отдельный стандарт, отписывающий формат зашифрованного JWT-токена.
 

diff --git a/tokens.md b/tokens.md
@@ -37,7 +37,7 @@ __Поскольку токены это не зашифрованная инф
 
 ## Схема использования токенов:
 1. Пользователь логинится в приложении, передавая логин/пароль на сервер
-2. Сервер проверят подлинность логина/пароля, в случае удачи генерирует и отправляет клиенту два токена(__access и refresh token__) и время смерти __access token'а__ (`expires_in` поле в __unix timestamp__)
+2. Сервер проверят подлинность логина/пароля, в случае удачи генерирует и отправляет клиенту два токена(__access, refresh__) и время смерти __access token'а__ (`expires_in` поле в __unix timestamp__)
 3. Приложение сохраняет токены и и время смерти __access token'а__, используя __access token__ для последующей авторизации запросов
 4. Перед каждым запросом клиент предварительно проверяет время жизни __access token'а__ (из `expires_in`)и если оно истекло клиент использует __refresh token__ чтобы обновить __ОБА__ токена и продолжить использовать новый __access token__
 

diff --git a/tokens.md b/tokens.md
@@ -48,15 +48,14 @@ __Ключевой момент__ что в момент рефреша то е
 С такой схемой юзер сможет быть залогинен только на одном устройстве. Тоесть в любом случае при смене устройства ему придется логинится заново.
 
 ## Схема рефреша токенов:
-1. Клиент отправляет запрос с истекшим __access token'ом__
-2. Сервер отвечает `{ success: false, accessTokenExpiredError: true }`
-3. Клиент отправляет на `auth/refresh-token` URL __refresh token__
-4. Сервер сравнивает __refresh token__ от клиента с __refresh token'ом__ лежащим в БД
-5. Сервер проверяет действителен ли срок действия __refresh token'а__
+1. Клиент проверяет перед запросом не истекло ли время жизни __access token'на__
+2. И если истекло клиент отправляет на `auth/refresh-token` URL __refresh token__
+3. Сервер сравнивает __refresh token__ от клиента с __refresh token'ом__ лежащим в БД
+4. Сервер проверяет валидность и срок действия __refresh token'а__
 6. В случае успеха сервер: 
     1. Пересоздает и записывает __refresh token__ в БД
     2. Создает новый __access token__
-    3. Отправляет оба токена клиенту
+    3. Отправляет оба токена и новый `expires_in` __access token'а__ клиенту
 7. Клиент повторяет запрос к API c новым __access token'ом__
 
 ## В случае кражи(обоих токенов):

diff --git a/tokens.md b/tokens.md
@@ -37,9 +37,9 @@ __Поскольку токены это не зашифрованная инф
 
 ## Схема использования токенов:
 1. Пользователь логинится в приложении, передавая логин/пароль на сервер
-2. Сервер проверят подлинность логина/пароля, в случае удачи генерирует и отправляет клиенту два токена(__access и refresh token__)
-3. Приложение сохраняет токены и использует __access token__ для последующией __авторизации запросов__
-4. Когда время жизни __access token'а__ закончилось и он приходит на сервер с истекшим сроком жизни, сервер отвечает "Token expired", далее клиент использует __refresh token__ чтобы обновить __ОБА__ токена и продолжить использовать новый __access token__
+2. Сервер проверят подлинность логина/пароля, в случае удачи генерирует и отправляет клиенту два токена(__access и refresh token__) и время смерти __access token'а__ (`expires_in` поле в __unix timestamp__)
+3. Приложение сохраняет токены и и время смерти __access token'а__, используя __access token__ для последующей авторизации запросов
+4. Перед каждым запросом клиент предварительно проверяет время жизни __access token'а__ (из `expires_in`)и если оно истекло клиент использует __refresh token__ чтобы обновить __ОБА__ токена и продолжить использовать новый __access token__
 
 __Ключевой момент__ что в момент рефреша то есть обновления __access token'a__ обновляются __ОБА__ токена. Но как же __refresh token__ может сам себя обновить, он ведь создается только после успешной аунтефикации ? __refresh token__ в момент рефреша сравнивает себя с тем __refresh token'ом__ который лежит в БД и вслучае успеха, а также если у него не истек срок, система рефрешит токены. __Внимание__ при обновлении __refresh token__ продливается также и его срок жизни.
 

diff --git a/tokens.md b/tokens.md
@@ -57,7 +57,7 @@ __Ключевой момент__ что в момент рефреша то е
     1. Пересоздает и записывает __refresh token__ в БД
     2. Создает новый __access token__
     3. Отправляет оба токена клиенту
-7. Клиент пробует повторить запрос к API c новым __access token'ом__
+7. Клиент повторяет запрос к API c новым __access token'ом__
 
 ## В случае кражи(обоих токенов):
 1. Хакер воспользовался __access token'ом__

diff --git a/tokens.md b/tokens.md
@@ -49,7 +49,7 @@ __Ключевой момент__ что в момент рефреша то е
 
 ## Схема рефреша токенов:
 1. Клиент отправляет запрос с истекшим __access token'ом__
-2. Сервер отвечает `{ success: false, accessTokenError: 'TokenExpiredError' }`
+2. Сервер отвечает `{ success: false, accessTokenExpiredError: true }`
 3. Клиент отправляет на `auth/refresh-token` URL __refresh token__
 4. Сервер сравнивает __refresh token__ от клиента с __refresh token'ом__ лежащим в БД
 5. Сервер проверяет действителен ли срок действия __refresh token'а__

diff --git a/tokens.md b/tokens.md
@@ -48,7 +48,7 @@ __Ключевой момент__ что в момент рефреша то е
 С такой схемой юзер сможет быть залогинен только на одном устройстве. Тоесть в любом случае при смене устройства ему придется логинится заново.
 
 ## Схема рефреша токенов:
-1. Клиент отправляет запрос с интекшим __access token'ом__
+1. Клиент отправляет запрос с истекшим __access token'ом__
 2. Сервер отвечает `{ success: false, accessTokenError: 'TokenExpiredError' }`
 3. Клиент отправляет на `auth/refresh-token` URL __refresh token__
 4. Сервер сравнивает __refresh token__ от клиента с __refresh token'ом__ лежащим в БД

diff --git a/tokens.md b/tokens.md
@@ -54,9 +54,9 @@ __Ключевой момент__ что в момент рефреша то е
 4. Сервер сравнивает __refresh token__ от клиента с __refresh token'ом__ лежащим в БД
 5. Сервер проверяет действителен ли срок действия __refresh token'а__
 6. В случае успеха сервер: 
-  1. Пересоздает и записывает __refresh token__ в БД
-  2. Создает новый __access token__
-  3. Отправляет оба токена клиенту
+    1. Пересоздает и записывает __refresh token__ в БД
+    2. Создает новый __access token__
+    3. Отправляет оба токена клиенту
 7. Клиент пробует повторить запрос к API c новым __access token'ом__
 
 ## В случае кражи(обоих токенов):

diff --git a/tokens.md b/tokens.md
@@ -54,10 +54,9 @@ __Ключевой момент__ что в момент рефреша то е
 4. Сервер сравнивает __refresh token__ от клиента с __refresh token'ом__ лежащим в БД
 5. Сервер проверяет действителен ли срок действия __refresh token'а__
 6. В случае успеха сервер: 
-
-6.1. Пересоздает и записывает __refresh token__ в БД
-6.2. Создает новый __access token__
-6.3. Отправляет оба токена клиенту
+  1. Пересоздает и записывает __refresh token__ в БД
+  2. Создает новый __access token__
+  3. Отправляет оба токена клиенту
 7. Клиент пробует повторить запрос к API c новым __access token'ом__
 
 ## В случае кражи(обоих токенов):

diff --git a/tokens.md b/tokens.md
@@ -54,6 +54,7 @@ __Ключевой момент__ что в момент рефреша то е
 4. Сервер сравнивает __refresh token__ от клиента с __refresh token'ом__ лежащим в БД
 5. Сервер проверяет действителен ли срок действия __refresh token'а__
 6. В случае успеха сервер: 
+
 6.1. Пересоздает и записывает __refresh token__ в БД
 6.2. Создает новый __access token__
 6.3. Отправляет оба токена клиенту

diff --git a/tokens.md b/tokens.md
@@ -54,10 +54,9 @@ __Ключевой момент__ что в момент рефреша то е
 4. Сервер сравнивает __refresh token__ от клиента с __refresh token'ом__ лежащим в БД
 5. Сервер проверяет действителен ли срок действия __refresh token'а__
 6. В случае успеха сервер: 
-
-  6.1 Пересоздает и записывает __refresh token__ в БД
-  6.2 Создает новый __access token__
-  6.3 Отправляет оба токена клиенту
+6.1. Пересоздает и записывает __refresh token__ в БД
+6.2. Создает новый __access token__
+6.3. Отправляет оба токена клиенту
 7. Клиент пробует повторить запрос к API c новым __access token'ом__
 
 ## В случае кражи(обоих токенов):

diff --git a/tokens.md b/tokens.md
@@ -54,6 +54,7 @@ __Ключевой момент__ что в момент рефреша то е
 4. Сервер сравнивает __refresh token__ от клиента с __refresh token'ом__ лежащим в БД
 5. Сервер проверяет действителен ли срок действия __refresh token'а__
 6. В случае успеха сервер: 
+
   6.1 Пересоздает и записывает __refresh token__ в БД
   6.2 Создает новый __access token__
   6.3 Отправляет оба токена клиенту

diff --git a/tokens.md b/tokens.md
@@ -54,9 +54,9 @@ __Ключевой момент__ что в момент рефреша то е
 4. Сервер сравнивает __refresh token__ от клиента с __refresh token'ом__ лежащим в БД
 5. Сервер проверяет действителен ли срок действия __refresh token'а__
 6. В случае успеха сервер: 
-6.1 Пересоздает и записывает __refresh token__ в БД
-6.2 Создает новый __access token__
-6.3 Отправляет оба токена клиенту
+  6.1 Пересоздает и записывает __refresh token__ в БД
+  6.2 Создает новый __access token__
+  6.3 Отправляет оба токена клиенту
 7. Клиент пробует повторить запрос к API c новым __access token'ом__
 
 ## В случае кражи(обоих токенов):

diff --git a/tokens.md b/tokens.md
@@ -54,9 +54,9 @@ __Ключевой момент__ что в момент рефреша то е
 4. Сервер сравнивает __refresh token__ от клиента с __refresh token'ом__ лежащим в БД
 5. Сервер проверяет действителен ли срок действия __refresh token'а__
 6. В случае успеха сервер: 
- - 6.1 Пересоздает и записывает __refresh token__ в БД
- - 6.2 Создает новый __access token__
- - 6.3 Отправляет оба токена клиенту
+6.1 Пересоздает и записывает __refresh token__ в БД
+6.2 Создает новый __access token__
+6.3 Отправляет оба токена клиенту
 7. Клиент пробует повторить запрос к API c новым __access token'ом__
 
 ## В случае кражи(обоих токенов):
@@ -77,6 +77,7 @@ __Проблема:__ Поскольку __refresh token__ продлевает
 - дополнительно шифровать токены (в nodejs например crypt >> aes-256)
 
 ### Чтиво:
+- https://tools.ietf.org/html/rfc6749
 - https://jwt.io/introduction/
 - https://auth0.com/blog/using-json-web-tokens-as-api-keys/
 - https://auth0.com/blog/cookies-vs-tokens-definitive-guide/

diff --git a/tokens.md b/tokens.md
@@ -72,7 +72,7 @@ __Ключевой момент__ что в момент рефреша то е
 
 __Проблема:__ Поскольку __refresh token__ продлевает срок своей жизни каждый раз при рефреше токенов >> хакер пользуется токенами до тех пор пока юзер не залогинится.
 
-### В случае паранойи:
+### В случае паранои:
 - хранить список валидных IP, deviceID, fingerprint браузера, генерить рандомный randomUserID
 - дополнительно шифровать токены (в nodejs например crypt >> aes-256)
 

diff --git a/tokens.md b/tokens.md
@@ -48,7 +48,7 @@ __Ключевой момент__ что в момент рефреша то е
 С такой схемой юзер сможет быть залогинен только на одном устройстве. Тоесть в любом случае при смене устройства ему придется логинится заново.
 
 ## Схема рефреша токенов:
-1. Клиент отправляет запрос с невалидным __access token'ом__
+1. Клиент отправляет запрос с интекшим __access token'ом__
 2. Сервер отвечает `{ success: false, accessTokenError: 'TokenExpiredError' }`
 3. Клиент отправляет на `auth/refresh-token` URL __refresh token__
 4. Сервер сравнивает __refresh token__ от клиента с __refresh token'ом__ лежащим в БД

diff --git a/tokens.md b/tokens.md
@@ -39,9 +39,7 @@ __Поскольку токены это не зашифрованная инф
 1. Пользователь логинится в приложении, передавая логин/пароль на сервер
 2. Сервер проверят подлинность логина/пароля, в случае удачи генерирует и отправляет клиенту два токена(__access и refresh token__)
 3. Приложение сохраняет токены и использует __access token__ для последующией __авторизации запросов__
-4. Перед каждым запросом клиент предварительно проверятет время жизни __access token'а__ и если оно закончилось клиент использует __refresh token__ чтобы обновить __ОБА__ токена и продолжить использовать новый __access token__
-
-
+4. Когда время жизни __access token'а__ закончилось и он приходит на сервер с истекшим сроком жизни, сервер отвечает "Token expired", далее клиент использует __refresh token__ чтобы обновить __ОБА__ токена и продолжить использовать новый __access token__
 
 __Ключевой момент__ что в момент рефреша то есть обновления __access token'a__ обновляются __ОБА__ токена. Но как же __refresh token__ может сам себя обновить, он ведь создается только после успешной аунтефикации ? __refresh token__ в момент рефреша сравнивает себя с тем __refresh token'ом__ который лежит в БД и вслучае успеха, а также если у него не истек срок, система рефрешит токены. __Внимание__ при обновлении __refresh token__ продливается также и его срок жизни.
 

diff --git a/tokens.md b/tokens.md
@@ -39,7 +39,9 @@ __Поскольку токены это не зашифрованная инф
 1. Пользователь логинится в приложении, передавая логин/пароль на сервер
 2. Сервер проверят подлинность логина/пароля, в случае удачи генерирует и отправляет клиенту два токена(__access и refresh token__)
 3. Приложение сохраняет токены и использует __access token__ для последующией __авторизации запросов__
-4. Когда время жизни __access token'а__ закончилось и он приходит на сервер не валидным, сервер отвечает "Token expired", далее клиент использует __refresh token__ чтобы обновить __ОБА__ токена и продолжить использовать новый __access token__
+4. Перед каждым запросом клиент предварительно проверятет время жизни __access token'а__ и если оно закончилось клиент использует __refresh token__ чтобы обновить __ОБА__ токена и продолжить использовать новый __access token__
+
+
 
 __Ключевой момент__ что в момент рефреша то есть обновления __access token'a__ обновляются __ОБА__ токена. Но как же __refresh token__ может сам себя обновить, он ведь создается только после успешной аунтефикации ? __refresh token__ в момент рефреша сравнивает себя с тем __refresh token'ом__ который лежит в БД и вслучае успеха, а также если у него не истек срок, система рефрешит токены. __Внимание__ при обновлении __refresh token__ продливается также и его срок жизни.
No results found