【ITニュース解説】Authentication & Authorization — JWT & OAuth 2.0

現代のデジタルサービスにおいて、ユーザーが安心して利用できるよう、セキュリティは非常に重要な要素である。その中でも「認証」と「認可」という二つの概念は、サービスの安全性と利便性を支える基盤となっている。認証とは、「あなたが誰であるか」を証明するプロセスである。例えば、ウェブサイトにログインするためにユーザー名とパスワードを入力し、それが正しい場合に「あなたが本人である」と確認されるのが認証だ。一方、認可とは、「あなたが何ができるか」を証明するプロセスである。例えば、ログイン後も、一般ユーザーは自分のプロフィールしか見られないが、管理者ユーザーは他のユーザーの情報を変更できるといったように、権限に応じてできることが異なるのは認可の働きによるものだ。

システムエンジニアがこれらの認証と認可の仕組みを構築する際、現在広く利用されている業界標準の技術に「JWT（JSON Web Token）」と「OAuth 2.0」がある。

まず、JWT（JSON Web Token）について説明する。これは、ユーザーに関する情報（クレームと呼ぶ）を自身の中に持ち、デジタル署名が施された自己完結型のデータ（トークン）である。JWTの大きな特徴は、その検証において、サーバーが毎回データベースを参照することなく、トークンの正当性を確認できる点にある。これにより、システムのスケーラビリティ（拡張性）が向上する。

JWTは三つの部分から構成されている。「ヘッダー」「ペイロード」「署名」の三つだ。 ヘッダーには、このトークンがどのような種類のトークンであるか、そして署名にどのアルゴリズムが使われたかなどの情報が含まれる。ペイロードには、ユーザーID、ユーザーの役割、トークンの発行時刻、有効期限など、ユーザーに関する具体的な情報が格納される。ただし、ペイロードの内容はエンコードされているものの、暗号化されているわけではないため、機密性の高い情報はここに入れないよう注意が必要だ。最後の署名は、ヘッダーとペイロードの内容、そしてサーバーだけが知る秘密鍵を用いて生成される。この署名があることで、トークンが途中で改ざんされていないかを確認できるのだ。もしヘッダーやペイロードが改ざんされると、署名と一致しなくなるため、サーバーはそのトークンを無効と判断できる。

JWTの一般的な流れは次のようになる。まず、ユーザーがメールアドレスとパスワードを入力してログインを試みる。サーバーは入力された情報が正しいか検証し、正しければ新しいJWTを生成してクライアント（例えばウェブブラウザやモバイルアプリ）に返す。次に、クライアントが何らかのAPIを呼び出してユーザー情報を取得したい場合、先のJWTをリクエストヘッダーに添付してサーバーに送信する。サーバーは受け取ったJWTをデコードし、有効期限が切れていないか、署名が正しいか、ユーザーにその操作を許可する権限があるかなどを検証する。これらの検証が成功すれば、リクエストされたユーザーデータをクライアントに返すという仕組みである。

この方式の大きな利点は「ステートレス」であることだ。ステートレスとは、サーバーがユーザーのセッション情報を保存しない状態を指す。これによって、どのサーバーインスタンスも秘密鍵さえあればトークンを検証できるため、システムを柔軟に拡張でき、大量のアクセスを処理しやすいというメリットがある。

しかし、JWTにもリスクは存在する。もしJWTが盗まれると、そのトークンの有効期限が切れるまで、第三者が不正に利用できてしまう可能性がある。この対策としては、JWTの有効期限を短く設定し、新しいトークンを取得するための「リフレッシュトークン」を併用する方法がある。また、有効期限内でも即座にトークンを無効化したい場合は、リフレッシュトークンをサーバー側のブラックリストに登録するといった仕組みが必要となる。ペイロードに格納された情報が可視であるため、機密性の高い情報を絶対に入れないことも重要である。

次に、OAuth 2.0（オーオース二ーテンゼロ）について解説する。これは、「委任された認可」を実現するための標準プロトコルである。最も身近な例としては、「Googleでログイン」や「GitHubでログイン」といった、他のサービスのアカウントを使って別のサービスにログインする機能が挙げられる。ユーザーは自分のパスワードを連携先のアプリに直接教えることなく、そのアプリに自分の情報（例えばメールアドレスやプロフィール）へのアクセスを許可できる。

OAuth 2.0にはいくつかのフローがあるが、推奨されているのは「認可コードフロー」である。このフローは次のような段階で進行する。 まず、ユーザーは利用したいクライアントアプリケーションで「ログイン」ボタンを押す。すると、クライアントアプリケーションはユーザーを認可サーバー（GoogleやGitHubなど、認証と認可を行う専門のサーバー）にリダイレクトする。ユーザーはここで認可サーバーにログインし、クライアントアプリケーションに対して自分の情報へのアクセスを許可するかどうかを選択する。ユーザーが許可すると、認可サーバーは「認可コード」という一時的なコードをクライアントアプリケーションに返す。クライアントアプリケーションはこの認可コードと、自分自身の秘密情報（クライアントシークレット）を認可サーバーに送信し、それと引き換えに「アクセストークン」と「リフレッシュトークン」を取得する。アクセストークンは短寿命で、クライアントアプリケーションがユーザーのリソースにアクセスするために使用する。リフレッシュトークンは長寿命で、アクセストークンの有効期限が切れた際に、新しいアクセストークンを取得するために使われる。アクセストークンを手に入れたクライアントアプリケーションは、このトークンを使ってリソースサーバー（例えばAPI）にアクセスし、ユーザーのプロフィール情報などを取得できるようになる。

OAuth 2.0にはいくつかの重要な概念がある。クライアントとはユーザーが利用するアプリケーションのこと。リソースオーナーは、自分の情報にアクセスを許可するユーザー本人である。認可サーバーは、トークンの発行やユーザー認証を担当する。リソースサーバーは、アクセストークンを受け取り、実際のデータを提供するAPIである。アクセストークンは、APIを呼び出すための鍵のようなもので、有効期限は比較的短い。リフレッシュトークンは、アクセストークンが期限切れになったときに、新しいアクセストークンと交換するための鍵で、有効期限は比較的長い。スコープとは、クライアントアプリケーションに許可する権限の範囲を指し、「メールアドレスの読み取りのみ許可」のように細かく指定できる。

認証情報をサーバー側で管理する「セッション方式」とJWTを比較すると、セッションはサーバーのデータベースなどにユーザー情報を保存するのに対し、JWTはクライアント側（ブラウザのローカルストレージやCookieなど）にトークンを保存する。セッションはサーバー側で情報を削除すれば即座に無効化できるが、JWTは有効期限まで待つか、別途ブラックリストを管理する必要がある。セッションはサーバーに負荷がかかりやすいが、JWTはステートレスであるため大規模システムに適している。セッションはモノリス（一つの大きなシステム）や比較的小規模なシステムでよく使われるが、JWTはマイクロサービスやAPI、モバイルアプリケーションとの連携に強みがある。

JWTとOAuth 2.0それぞれのメリットとデメリット、そして適切な利用シーンを理解することは重要だ。 JWTのメリットは、サーバーがステートレスであるためスケーラビリティが高く、リクエストごとにデータベースを参照する必要がない点である。これにより、複数のマイクロサービス間でのユーザー認証情報の受け渡しも容易になる。デメリットとしては、有効期限が来るまでトークンを即座に無効化するのが難しいこと、ペイロードの内容が誰にでも可視であること、そしてトークン自体が長くなることで通信オーバーヘッドが増える可能性がある点が挙げられる。 OAuth 2.0のメリットは、ユーザーがパスワードを共有することなく、サードパーティアプリケーションに特定の情報へのアクセスを許可できる点、そしてアクセスを許可する範囲（スコープ）をきめ細かく設定できる点、さらにシングルサインオン（一度の認証で複数のサービスが利用できる）の業界標準として広く使われている点にある。デメリットとしては、そのフローが比較的複雑であるため、設定を誤ると重大なセキュリティ脆弱性につながる可能性があること、またトークンが漏洩した場合のリスクが存在することである。

これらを踏まえ、JWTは、モバイルアプリやSPA（シングルページアプリケーション）にRESTful APIを提供するバックエンドシステム、複数のマイクロサービス間でユーザーの識別情報を受け渡したい場合、あるいはステートレスで水平方向にスケールする（サーバー数を増やして処理能力を高める）バックエンドを構築したい場合に適している。 一方、OAuth 2.0は、「Googleでログイン」のようなサードパーティサービスとの連携を実装したい場合、外部のアプリケーションに自社サービスのユーザーデータへのアクセスを許可したい場合、または企業内の複数のシステムで統一された認証基盤（エンタープライズSSO）を実現したい場合に利用するのが適切である。 逆に、即座のログアウトやトークン失効が必要なシステム、あるいはペイロードの内容の可視性が問題となる極めて機密性の高いシステムでは、JWTの利用は避けるべきである。このような場合は、セッション管理など、他の方式を検討することが望ましい。

システムエンジニアとして、これらの技術を適切に選択し、設計、実装することは、安全で信頼性の高いサービスを提供するために不可欠なスキルである。