はじめに

『スタディサプリ』の小中高プロダクト基盤開発グループの認証チームでインターンシップをしていました。立命館大学3年の中尾です。今回は RECRUIT INTERNSHIP for Engineers 2024に参加させていただいたので、携わった案件と取り組んだタスクについて書いていこうと思います。この記事を読むことで、『スタディサプリ』のインターンシップ面白そう！と思ってもらえたら嬉しいです。

 

『スタディサプリ』の開発組織について知りたい方は、こちらの方の記事を読んでいただければと思います！

 

案件について

今回私は、『スタディサプリ』の導入校の生徒さん向けに、ソーシャルログインの機能を追加するプロジェクトに1メンバーとして参画しました（インターンシップでは実際に働く社員さんのチームプロジェクトにジョインすることができます）。

ソーシャルログインとは、GoogleやMicrosoftなどのアカウント用いて、他のサービスにログインできる機能です。皆さんも一度は使ったことがあるのではないでしょうか。

 

この機能を追加するに至った理由は、『スタディサプリ』を導入してくださる組織の負担の軽減です。

たとえば、生徒さんがスタディサプリのアカウントのパスワードを忘れてしまった際、再発行の作業をする必要があります。『スタディサプリ』にログインする頻度は Google や Microsoft などにログインする頻度に比べて少ないため、パスワード忘れが発生するリスクが高く、その分手間がかかりやすいです。

『スタディサプリ』の導入を検討してくださる学校の多くがGoogleやMicrosoftのサービスを学校単位で利用しているため、ソーシャルログイン機能を追加することで、この負担が軽減されます。

取り組んだこと

私は Google アカウントを用いたログインの実装を担当しました。

OpenID Connect（OIDC）という ID 連携の規約に沿って実装しました。

 

Googleアカウントを用いた認証の方法

Google アカウントで『スタディサプリ』にログインするために Google アカウントとスタディサプリアカウントを連携させる必要があります。

 

つまり以下のステップを踏む必要があります。

1. Google アカウントを『スタディサプリ』のアカウントに連携する

2. Google アカウントで『スタディサプリ』にログインする

 

ここでは 「2. Google アカウントで『スタディサプリ』にログインする」のフローを紹介します。

 

 

ID トークン

9 番で登場する ID トークンは JWT（JSON Web Token）形式で発行され、これは「誰が」「どのサービスのために」「いつまで有効な」トークンなのかを安全に伝えることができる標準規格です。

 

具体的には以下のような情報が含まれています

 

1. トークンの発行者（Issuer）

• 「誰が発行したトークンか」を示します

2. 利用者（Audience）

• 「どのサービスのために発行されたトークンか」を示します

3. ユーザの識別子（Subject）

• 「どのユーザのトークンか」を示す一意の識別子です

4. トークンの有効期限（Expiration Time）

• トークンがいつまで有効なのかを示します

5. 電子署名

• トークンの内容が改ざんされていないことを証明します

 

これらの情報によって、この ID トークンがスタディサプリのために発行されたものであることを検証することができます。

例えば、Google アカウントを用いた認証機能を持つ別のサービス A があるとします。サービス A とスタディサプリの両方を使っているユーザ B がいた場合、サービス A の運営者が、サービス A にログインするために発行されたユーザ B のトークンを使って、スタディサプリにログインするといった攻撃を防ぐことができます。

署名が付与されているので、ID トークンのクライアント ID だけスタディサプリのものに変えて送信するといった攻撃も行うことができません。

 

学校ごとの制御

学校ごとに「生徒が Google 認証を使用するのを許可したくない」や「学校のメールアドレスのドメインを持っているので、そのドメインのメールアドレスのアカウント以外では紐付けできないようにしたい」といったニーズが考えられます。

そこで、学校ごとに Google や Microsoft などのアカウントを用いたソーシャルログインの機能を許可するかどうかを検討し、ソーシャルログインに用いるメールアドレスのドメインを制御できるようにしました。

 

セキュリティの検討

OIDC を利用したソーシャルログインには対応すべき脆弱性がいくつかあります。

ここではその一例として、CSRF 攻撃について説明します。

 

一般的に CSRF 攻撃とは、メールなどで URL を被害者にクリックさせることで、意図しないリクエストを送信させる攻撃です。

OIDC における CSRF 攻撃に言い換えると利用者が意図せず認証レスポンスをアプリに送信してしまうことです。

 

例えば、取得したリダイレクト先のURLを被害者にクリックさせることで、攻撃者のスタディサプリアカウントと被害者のGoogleアカウントを紐づけることができます。こう聞くと一見無害そうに見えますが、被害者が攻撃者のアカウントにログインしていることに気づかずにクレジットカード情報や個人情報を登録してしまった場合、問題が発生します。

 

このような CSRF 攻撃への一般的な対策として、state パラメータを使用する方法があります。

 

state とセッションを紐付けて管理することで認証リクエストのセッションと認証レスポンスのセッションが同一であることが担保できます。このように一連の流れが一つのセッションで行われることを確認することで CSRF 攻撃を防ぐことができます。

 

プロジェクトでは、このような一般的な攻撃パターンの理解を踏まえた上で、実際の要件や運用環境に即して、どのような脅威が存在し得るのか、それぞれの脅威に対してどのような対策が最適なのかを、プロジェクトメンバーとともに慎重に検討しました。

 

最後に

ビジネス的にも重要で、技術的にも面白いプロジェクトに携わることができ、とても実りのある1ヶ月間でした。

ありがとうございました！！！！！！