Cookie(Session)での認証と Token での認証の違いについて

Cookie(Session)での認証と Token での認証の違いについて
------------------------------------

1. はじめに

2. Cookie(Session)による認証方式

3. Token による認証方式

4. Cookie(Session)と Token のメリット・デメリット

5. まとめ

6. 参考

-------------------------------

Cookie(Session)での認証と Token での認証の違いについて

はじめに

現在開発中の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)のメリット・デメリット

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

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

 

参考