TokenとUUIDの認証コードの違いを理解する話

Webサービスでログイン機能や、決済機能を作る時に、認証が必要になり、必ずと言っていいほどToken（トークン）を扱うことになります。 エンジニアではない人は、トークン？と思う人もいるかもしれないので、今回はエンジニアトークとトークンの違いを説明する書いではなく、 認証におけるTokenについての理解を深めるブログを書いておきます。 Webエンジニア以外の人は、あまり面白くないと思うので、すっ飛ばしてくださいませ。

Tokenとは？

認証やアクセス制御のために発行される、一時的なデジタル鍵

よく、Webサービスの会員登録をするときや、パスワード変更をする際などに、メールで送られてくる意味不明な英数字が並んでいるコードが送られてきますが、 これが、Tokenであり、認証コードです。（そうじゃない場合もありますが・・・） 圧縮形式である、JWT（ジョット）にエンコードされた文字列が使われる事が多いですが、代表的なモノは、次のような形式があります。

JWT：署名付きで、ユーザー情報や期限などを含められるトークン Opaque Token：中身がわからないランダム文字列型のトークン（API側で意味を持たせる） OAuth Access Token / Refresh Token：外部サービス認可用トークン CSRF Token：フォーム送信時の偽造防止用トークン

Tokeは、時間経過に伴い、ランダムな値で発行されるため、以降に同じ値を持たないデータとして、認証確認で使われる事が多いんですね。

TokenとUUIDの違い

自分、ずっと勘違いしていたんですが、UUIDとTokenは同じだと思っていたんですよ。 でも、UUIDは、「一意な識別子」を生成する仕組みであり、認証に特化した値ではないんですね。 認証トークンは「セッションやユーザーの認証状態を安全に識別するための文字列」でなければいけないため、 署名や暗号化、期限、有効範囲などのセキュリティ情報が含まれる場合が多い。 UUIDは、ランダム性はあるが署名や期限情報は持たないため、そのままでは安全性が低い。 実際の認証では、UUIDをトークンの一部に使うことはあるが、JWT（JSON Web Token）やランダムバイト列（Base64エンコード）などを利用する事が多い。 まとめると、「UUID＝識別子」「認証トークン＝識別子＋セキュリティ機能」で別物という事になる。

なぜTokenが必要なのか？

セキュリティ向上のためにTokenは不可欠です。 毎回ユーザー名とパスワードを送るのは危険だし、そもそもパスワードなどが漏れた時点で、認証の意味が無くなる。 Tokenは一時的な鍵として使えるので、漏れても時間で失効するとう利点がある。 また、効率化という視点でも、サーバー側でユーザー情報を保持し、Tokenで素早く照合する事ができるようになる。 状態の引き継ぎとして、モバイルアプリや別ページ遷移後もログイン状態を維持することもできるワケですね。 例えば、ECサイトでログイン後に買い物かごに商品を入れると、ページを移動しても中身が消えないのは、Tokenで状態管理されているからです。（そうじゃない場合もあるけど）

Tokenの寿命と管理

Tokenは永遠に使えるわけではないという特性がある。 有効期限（数分〜数時間）を過ぎると、自動的に無効化されるのが基本。 期限切れ後は、新しいTokenを発行する「リフレッシュ」の仕組みが必要になるが、これが安全性につながる。 保存先はブラウザのCookieやLocalStorageだが、セキュリティ対策（HttpOnly属性や暗号化）が必須になるので、こうした点での理解も必要になる。

Tokenの落とし穴

安心安全に思われがちなTokenですが、そもそも盗まれたら即アウトなデータなんですよ。 第三者にTokenを奪われると、その人になりすまされるというのは、IDとパスワードと同じ。 これは、現在の認証ロジックにおいて、仕方のないことでもありますね。 無期限Tokenは危険なので、発行しっぱなしにすると、悪用のリスクが増えるので、技術者はこうしたリスクヘッジと技術ポイントを理解しておかなければいけないのが事実。 平文送信はダメというのは、Webデータ送受信においては鉄板です。 必ずHTTPSで暗号化通信することは、もはやWebの鉄則ですね。

まとめ

- Tokenは「一時的なデジタル鍵」で、認証やアクセス制御の中核。 - UUIDとは違い、セキュリティ機能や期限を組み込むのが普通。 - 正しく使えば安全で便利だが、管理を誤ると大きなリスクになる。 - Webサービスやアプリを作るなら、Tokenの仕組みと安全運用は避けて通れない知識。

一度、Tokenを使ったやり取りを学習して実装する経験があれば、次回以降は比較的安定した構築ができるようになるでしょう。 ランダムコードで、なりすましを防御できる方法がTokenの仕組みですが、万が一になりすませてしまうリスクは少なからずあります。 もっと効率的で安全な方法を見つける事ができたら、それはWebサービス構築において極めて前進的な技術になりえるかもしれませんね。 あ〜そういうの発明してみたいな〜！