はじめに

現在開発中の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の開発が活発で、認証方法で調べ物をすることもあるかと思います。

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

参考

今すぐシェアしよう!
今すぐシェアしよう!