cookie, session, tokenを区別するために前提として理解してほしいことは、
「httpにはステートレス」ということです。

ステートレス

ステートレス、つまり状態を持たないことです。
誰からリクエストが来たのかを覚える必要は一切なく、ただただリクエストに対してレスポンスを返せばいいのです。
しかし、webアプリケーションが進化するようになってから、httpがステートレスの状態だとUserにとってとても困ります。
httpがステートレスのため、ログインしても、自分が過去にいいねした商品、ショッピングカートに入れた商品が見れません。

Sessionによる認証

そこで頭のいい人は、Session idを使ってhttpをステートフルにするための方法を考えました。
session idはただの文字列だと思って大丈夫です。Session idはweb serverから生成し、Userに割り当てします。また、違うUserがもらったsession idは違います。次回からhttp requestが送られる際に、session idも一緒に添付されます。
このsession idを持って、web serverが誰から来たのリクエストを判断することができます！同じsession idのため、過去のリクエストの内容ももちろん確認することができるため、httpはステートフルになりました！

Sessionによる認証のデメリット

しかし、session idは全部web serverから生成し、web serverはみんなのsession idを保存しないといけないため、とても大変です。
そうです、実はserverに大きな負担をかけています。またweb serverの拡張能力を制限しています。
例えば、serverAがツヤさんのリスエクトをリダイレクト処理でserver Bに転送されました。server Bはツヤさんのsession idを持っていません。これを解決するため、ツヤさんのsession idをserver Aからserver Bにコピーしなければいけません。
もっと楽にsession idを確認する方法はないかなと、session id保存用のserverを構築して、毎回リクエストが来たら、
server Aとserver Bもそこからsession idを確認すればいいじゃんと考えている方もいると思いますが、実はそれもリスキーです。例えば、ある日にsession id保存用のserverがダウンしたら、大変なことになります。説明からわかったように、sessionによる認証の管理が大変です。

Tokenによる認証

そこで、違う視点から問題を解決する方が現れました。なんでsession idはserverで保存しないといけないの？　webブラウザで保存すればいいじゃない。
しかし、web serverで保存しないと、どうやってこれかのsession idはweb serverが生成したものだと証明できるのですか？ここからはTokenの出番です。
例えば、ツヤさんがあるショッピングサイトをログインしました。
web serverがTokenを生成し、Tokenの中にツヤさんのUser idが含まれていて、ツヤさんに渡しします。
次回からツヤさんが訪問する際に、Tokenをhttp Headerに入れて、web serverを訪問します。またTokenを偽造できないように暗号化する必要があります。
例えばHMAC-SHA２５６のアルゴリズを使って、Tokenのデータを暗号化します。
このTokenについて、 web serverは保存しません。次回、ツヤさんが来た際に、同様なアルゴリズを使って、Tokenのデータを暗号化します。この二つの暗号化の結果を比較します。
こもし同じであれば、ツヤさんが登録済みのことがわかります。直接ツヤさんのUser idを受け取ります。もし違っていれば、データは改ざんされたことが推測できます。
また、Tokenの中のデータは明文保存のため、誰かに見られる可能性はあります。そのために、暗証番号のような秘密情報はTokenに入れてはいけません。
これでweb serverの負担は大幅軽減されました。やることとしては、Tokenを生成し、Tokenの認証だけです。sessionを保存するためのスペースが空きました。

Cookie

webブラウザが永久に保存できるデータのことです。 Cookieはweb serverが生成し、webブラウザに送ります。ブラウザがCookieをstorageに保存します。
次回同じサイトをアクセスする際に、そのCookieをweb serverに送ります。一般的にCookieのサイズは小さいです。

Session

例えば、誰かと会話する際に、今会話している対象が誰なのかを判明するため、Sessionを使います。Sessionの情報はweb serverに保存されます。
web serverがsessionの情報を臨時にweb serverに保存します。Userがブラウザを閉じたら、web serverに保存されたsession　idが自動に削除されます。そのため、ブラウザが閉じられた後のアクセスについて、web serverがまた新しいsession idを生成してブラウザに渡します。
Sessionによる認証のデメリットとしては、リクエストがあるたびに、web serverでSessionの参照と保存を行います。そのため、処理が遅くなるのが考えられます。

最後に

基本的に大規模の開発ではToken認証が主流です。
Token認証については、サーバ側で情報を管理しませんので、ステートレスとなります。並列処理も実施しやすくなります。大規模の開発ではToken認証の方が適しています。また、ネイティブアプリの開発にCookieの保存ができないので、Tokenは向いています。 Token認証の方が安全性が高いです。特にCSRFを防ぐために有効です。
CSRFについて話すと、長くなりますので、次回に書きたいと思います。

Tokenを使うことによって、Sessionに対する操作が減り、Tokenには時効もあるため、安全性が向上されます。
Token認証のデメリットとしては、TokenのデータサイズはSessionより大きいです。ブラウザでTokenを管理する場所として、LocalStorageかCookieに保存できます。また、Cookieは保存上限が4KBのため、保存する際に注意が必要です。