Коли доцільно використовувати cookies, а коли tokens для авторизації?

Багато читав про авторизацію через сесії/куки, на своєму сайті створив саме таку авторизацію, не бачу в ній мінусів.

Тепер починаю читати за токени, точніше за реалізацію авторизації через токени. Поки що не розумію чим саме не підходять куки? Токени — це той же ідентифікатор, який треба шукати десь в БД...

Які я бачу зараз для себе можливі переваги токена перед куками:
1. авторизація тих клієнтів, які просто не мають механізму куків (тобто користувачі заходять не через веб-браузер);
2. в токенах можна зберігати більше інформації;
3. для токенів не потрібен захист від CSRF, бо вони не видаються клієнтом автоматично на кожен запит, як це відбувається із куками.

По першому пункту — хіба багато таких клієнтів, хіба не 99,9% користувачів використовують браузер?

По другому пункту — а нащо взагалі там зберігати щось окрім ідентифікаторів, по яким потім можна нарити більше інформації...

Хм, зараз подумав, що може можна при створенні токена записати основні права, зашифрувати записане, а потім, при запитах від користувачів, навіть не шукати інформацію в БД, а зразу зчитувати її з токена й довіряти їй без перевірки... хоча чи безпечно таке робити?

Оновлення від 2016-07-23 19:53
Спочатку пропустив лінк на специфікацію (подумав що сильно нудно її читати =), але зараз бачу, що вона досить чітко описує нащо потрібні, в даному випадку, так звані Bearer Token

The access token provides an abstraction, replacing different
   authorization constructs (e.g., username and password, assertion) for
   a single token understood by the resource server.  This abstraction
   enables issuing access tokens valid for a short time period, as well
   as removing the resource server's need to understand a wide range of
   authentication schemes.

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

                     Figure 1: Abstract Protocol Flow

   The abstract OAuth 2.0 flow illustrated in Figure 1 describes the
   interaction between the client, resource owner, authorization server,
   and resource server (described in [RFC6749]).  The following two
   steps are specified within this document:

   (E)  The client requests the protected resource from the resource
        server and authenticates by presenting the access token.

   (F)  The resource server validates the access token, and if valid,
        serves the request.

   This document also imposes semantic requirements upon the access
   token returned in step (D).

Оновлення від 2016-07-25 00:20
Поки що зупинився на варіанті зашифрованих куків, в яких зберігається не лише ідентифікатор користувача, а і трохи більше інфи (раніше я зберігав дані сесії в БД): Using secure client-side sessions to build simple and scalable Node.JS applications

Оновлення від 2016-07-25 10:43
У підходу «зашифруємо куки, щоб не використовувати БД, і щоб було побільше, так би мовити, stateless» — є серйозний мінус якраз у тому таки stateless, бо якщо ви захочете комусь змінити роль/права/пароль, чи відправити когось у баню, то у вас не буде можливості це зробити аж поки старі куки не втратять свою актуальність. Це буде особливою проблемою, коли кукам автоматично продовжують термін актуальності.