サイオステクノロジーの佐々木です！ 今月の輪読会テーマはOAuth2.0とOpenIDConnectについてだったのですが、今まであまり勉強したことがない領域だったのでかなり苦戦しました。
今回学習した内容の中で疑問に思ったことがありました。
認可で使用するはずのOAuth2.0をなぜ認証で使っているのか？
これはTwitterを使用したログインを見てもらえるとわかるのですが、twitterはOAuth2.0+PKCEでやっています。
認証の規格があるのになぜこんなことをしているのか。。 歴史を知ることでどういった経緯でこうなっているのか知ることができると思ったので、認証認可の歴史を今回は調べてみました。
OAuthの歴史
OAuth1.0
OAuth 1.0は、消費者によるデータアクセスを開発者に許可するためのプロトコルとして、2006年頃に開発され始めました。この時期、ユーザーが自分のデータにアクセスするために直接ユーザー名とパスワードを共有するという、セキュリティ上問題のある方法をとっていました。このような背景から、OAuth 1.0はユーザーの資格情報を直接共有することなく、第三者アプリケーションがリソースにアクセスできるようにする目的で生まれました。
しかし、OAuth 1.0は複雑さと実装が困難という問題がありました。
OAuth2.0
OAuth1.0であった問題を解決するために、OAuth 2.0はより簡単で柔軟性のあるフレームワークを提供することを目指して設計されました。これは、より広範なユースケースとプラットフォームをカバーするためのものでした。
OAuth 2.0の開発は2009年に始まり、2012年10月にIETF (Internet Engineering Task Force) によってRFC 6749として正式に承認されました。
OAuth 2.0は、従来のパスワード共有の問題を解決するだけでなく、さまざまな種類のアプリケーションに対応できる設計がされています。また、クライアントが特定のリソースにのみアクセスできるスコープを定義する機能も提供しています。
現在では、OAuth 2.0はウェブ、モバイル、デスクトップアプリケーションなど、さまざまな種類のアプリケーションの認可のためのデファクトスタンダードとなっています。
OpenID Connect
OpenID Connectは、ユーザー認証に関する情報を提供するための単純なID層として、OAuth 2.0プロトコルの上に構築されたものです。OpenID Connectの開発はOpenID Foundationによって行われ、その目的は、Web上でのセキュアなユーザー認証のためのデファクトスタンダードを作ることでした。
その開発の背景には、Web上でのユーザー認証が複雑で非効率的なプロセスであるという課題がありました。従来の認証方法は、ユーザーが各サービスごとにユーザーネームとパスワードを作成・管理する必要があり、その結果、多くのセキュリティリスクが生じていました。
この問題を解決するために、OpenID ConnectはOAuth 2.0の上に構築されました。これにより、OpenID ConnectはOAuth 2.0の認可フローを継承しつつ、IDトークンと呼ばれる新たな要素を導入しました。このIDトークンはJSON Web Token（JWT）としてエンコードされ、認証されたユーザーに関する基本的な情報を含んでいます。
結局なぜTwitterはOAuthを使用しているのか
結論、明確な答えは出ませんでしたが、以下に仮説を上げてみます。
- OAuth1.0で認証を実装していてOpenID Connectを使用するよりもOAuth2.0+PKCEを利用したほうが実装コストが少ない
- Twitter認証を利用しているユーザーもOAuthを使用する想定で実装をしているので今更変える必要がない
- Twitterでの認証を使用しているサービスが多いので、Twitter側の実装に合わせてアプリケーションが実装してくれるのでOpenID Connectをわざわざ実装する必要がない
- Twitterの認可のみを使用したいサービスもあるためOAuthを採用して、多様なニーズに1つのAPIで対応できるようにしている
こんなところでしょうか？
もしこちらの事情に詳しい方がいましたら是非教えてください！
