SSO認証は本当に安全？気を付けるべきセキュリティポイントとは？～Open ID Connectについて～

前回はSSO（Single Sign-On）認証の特徴と、それを実現するための手法の一つであるSAML（Security Assertion Markup Language）について解説しました。今回は、OIDC（Open ID Connect）と、その基盤技術となるOAuth2.0について解説します。

OAuth/OIDCブログ

OAuth 2.0とは？

まず、OAuth 2.0について簡単に解説します。OAuth 2.0は、ユーザーが他のアプリケーションにパスワードを共有せずにリソースへのアクセスを認可するためのプロトコルです。これにより、ユーザーは自身のパスワードを提供せずに安全にアプリケーションにアクセス権を付与できます。例えば、OAuth 2.0はSNSアカウントを使って他のサービスにログインする際などに利用されます。

OAuth 2.0の主な役割は、ユーザーのリソースへのアクセスを管理することです。ユーザーがリソースへのアクセスを認可することで、アプリケーションがユーザーの情報を取得したり、リソースの参照・変更・削除などの操作を代理したりすることが可能となります。ただし、OAuth 2.0はあくまで認可を目的としているため、これを認証の代わりとして使用すると脆弱性が生じる可能性があります。こうした点には留意が必要です。

OIDC（Open ID Connect）とは？

OIDC（Open ID Connect）が登場する以前は、OAuth 2.0をそのまま認証代わりとして使用したり、企業が独自の拡張を行ったりしていました。そんな中で高まってきたのが、便利なSSOへのニーズやOAuth2.0を用いて認証を行いたいといった課題感。それらを解決するために、OpenID FoundationによってOAuth 2.0の拡張プロトコルであるOIDCが開発されました。

OAuth 2.0では、認可手順に関する仕様しか策定されていないため、OIDCでは認証に関する仕様（IDトークンの発行方法）を拡張して策定しています。

OIDCの仕組み

前提として、OIDCはOAuth 2.0の拡張仕様のため、基本的なフローや登場人物はOAuth 2.0とほとんど同じです。大きな違いとしては、OIDCを利用している場合はアクセストークンと一緒にIDトークンが発行されること。ただし注意点として、OAuth 2.0とOIDCでは別の単語でも同様のものを指している場合があります。本ブログではOAuth 2.0での用語を用いて解説します。

また、OAuth 2.0/OIDCには、複数の認可フローが存在します。

※以下のフロー以外にも、RFC等で定義されているフローはいくつかあります。

1. 認可コードフロー
2. インプリシットフロー
3. リソースオーナー・パスワード・クレデンシャルズフロー
4. クライアント・クレデンシャルズフロー
5. ハイブリッドフロー

その中でも、もっとも一般的で安全な実装である認可コードフローについて解説します。

認可コードフローの詳細

このフローは、主にサーバサイドアプリケーションで使用されます。クライアントがユーザーの認可を得た後に認可コードを取得し、そのコードを認可サーバに送信してトークンを取得します。そのため、パスワードをクライアントに隠ぺいしつつ、アクセストークンの発行時にクライアントを認証することができます。以下に認可コードフローの手順を簡単に解説します。

認可コードフローは以下の手順で行われます。

1. 認可リクエストの送信
   クライアントアプリケーションは、ユーザーを認可サーバにリダイレクトし、ユーザーの認可を求めます。このリクエストには、クライアントID、リダイレクトURI、スコープ等が含まれます。ユーザーが認可を与えると、認可サーバは認可コードをリダイレクトURIに送信します。
2. トークンリクエストの送信
   クライアントは、認可コードとともに認可サーバにトークンリクエストを送信します。このリクエストには、クライアントIDとクライアントシークレットも含まれます。
3. アクセストークンとIDトークンの受け取り
   認可サーバは、リクエストを検証し、アクセストークンおよびIDトークンをクライアントに送信します。

OAuth 2.0/OIDCのセキュリティのポイント

SAML同様、OAuth 2.0/OIDCにもセキュリティリスクがあります。ここでは代表的な攻撃例と、その対策を紹介します。

認可コード横取り攻撃

認可コード横取り攻撃は、認可サーバによって発行された正規の認可コードを、悪意のあるサードパーティのアプリ等が横取りをし、それを利用してアクセストークンを取得することを目的とした攻撃です。スマホアプリ等で、正規のアプリが送った認可リクエストに対し、認可コード発行時のコールバックURLにカスタムURLスキームが利用されていた場合に、悪意のある別アプリへ認可コードが漏えいしてしまう等のリスクが想定されます。

【主な対策】

PKCE（Proof Key for Code Exchange）の実装を行うことです。PKCEは、クライアントがverifierとchallengeを生成し、認可URLにリダイレクトする際に、challengeを送信します。その後、アクセストークンの発行時に、認可コードとverifierを送ることで、認可サーバが先に送っていたchallengeとの整合性を確認。その結果、不正な値であればアクセストークンを発行しないといった対応をすることで対策を行います。

まとめ

Open ID Connectは、SSO認証を実現する一つの方法として広く利用されていますが、セキュリティリスクも存在します。リスクを最小限に抑えるためには、トークンの管理やセキュリティ対策の実装が欠かせません。クライアント側でも適切な対策を講じ、ユーザーのリソースを守ることが重要です。なお、本記事で取り上げた脆弱性はあくまでOAuth 2.0/OIDCにおける一例となっております。

ユービーセキュアでは、OAuth 2.0/OIDCを利用したシステムや、認証基盤にOIDCを利用しているシステムに特化した診断も行っております。 少しでも気になることがございましたら、お気軽にご相談ください。