はじめに

現在開発中のAPIにおける認証の方式で、Tokenによる認証と、Cookie（Session）による認証のどちらを採用するか考えた時に、その違いについて学んだので記事にしました。

Cookie（Session）による認証方式

Cookieとは、Webサーバーがクライアント（PC等）に預けておく極小さなファイルのことをさします。

クライアントがWebサーバーに初めて接続（Login）した際に、Webサーバーがクライアントに対してCookieファイル（SessionID）を発行し、HTTPレスポンスのヘッダを利用して送ります。その際に発行されたSession情報（SessionID）にはログイン情報が含まれます。

次回以降、クライアントがWebサーバーへアクセスした際は、リクエストヘッダに含まれるCookie（SessionId）をサーバーが参照し、実際にサーバーに保存されているSession情報と合致した際に認証されたとみなされます。

Token による認証方式

Tokenによる認証も、Cookieと同じく、まずはクライアントがWebサーバーに接続（Login）した際に、Tokenが返されます。ただ、ここで違うのは、サーバーにその情報を保存はしません。「認証に成功した」というToken（いわゆる「認証情報」）を持ち、リクエストする度にリクエストヘッダにTokenを含んで送っています。

Cookie（Session）と Token のメリット・デメリット

Cookie（Session）のメリット・デメリット

Cookie（Session）のメリットを端的に言うならば、Statefull （状態の保持）ができることです。

 →これは例えばECサイトで例えるといいかと思います。（極端な話ですが…）

  ECサイトでは商品を買い物かごへ入れる、購入手続きをするというようにページ遷移が必ずあります。

  その際、Stateless（状態を保持しない）なサイトだった場合どうなるでしょうか。

  状態を管理しませんので、買い物かごはリセットされ購入に至りませんね。これでは困ります。

  そこでCookieで状態保持をさせることで、遷移してもその情報を保持し、購入に至ることができます。

  その点は Stateless の Token とは違うメリットです。

しかし、サーバー側で状態管理をしていることになりますから、リクエストのたびにサーバーでSession情報の参照と保存を行います。そのため、わずかながらに処理が遅くなると考えられる点がデメリットです。

Tokenのメリット・デメリット

StatelessなToken認証では基本的にはサーバーで認証の状態管理はしませんので、送られて来たTokenを検証するだけで済みます。

 そのため、サーバー側では並列分散が容易でスケーラブルになります。規模が大きくなるようなサービスでは、Tokenの認証方式の方が適しているかもしれません。

また、モバイルなどの場合、Cookieの保存ができないことがあるので、Tokenはネイティブアプリの開発に向いています。

そのため弊社のPassport（Career Passport）の開発でもTokenを利用しています。

デメリットはというと、TokenのデータサイズはCookieのSessionに比べ大きくなることです。クライアント側でTokenを管理する場所として、LocalStorageかCookieに保存する方法があります。しかし、Cookieに保存する際に上限が4KBと制約がつくため、注意が必要です。

まとめ

最近ではAPIの開発が活発で、認証方法で調べ物をすることもあるかと思います。

メリットデメリットを確認して、開発するサービスにベストな認証方法をえらんでいただきたいと思います。

参考

• https://qiita.com/hirohero/items/d74bc04e16e6d05d2a4a
• https://qiita.com/doyaaaaaken/items/02357c2ebca994160804