1:はじめに
こんにちは！新入社員の伊藤です。
Webアプリケーションの保守運用を担当するチームに配属されて半年が経ち、現在社内研究活動でソーシャルログインについて勉強を進めています。
ソーシャルログインは、LINE,Google,Yahooなどのアカントを用いて、Webアプリケーションにログインする仕組みです。 皆さんも何気なく使ったことがあるのではないでしょうか？
自分も今回の活動に取り組むまでは、何気なく使っていたソーシャルログインですが、開発者の視点で調査を進めるうちに、 「あれ？ これってどういう仕組みなんだろう？」と疑問に思うことがありました。
そこで今回は、調査の中で気になった点と、調べて分かったこと、実際にソーシャルログインの実装をしてつまづいた点などを踏まえて、紹介していきたいと思います！
2:意図しないデータ共有について
最初に気になったのは、ログイン後のデータが開発者側にどれくらい見えているの？という点でした。
例えば、
LINEでログインすると開発者に自分の友達リストが見えてしまうのか？
GoogleでログインするとGoogleカレンダーの情報まで取得されるのか？
といった、ユーザのプライバシーに関する疑問が出てきました。
結論として、ユーザの認証なしにデータが共有されることはありません！
ユーザの意図しないデータ共有は、OAuthという技術によって適切に制御されています！
OAuthとは
Webサービス間の連携において、外部からのデータやサービスに対するアクセスを、利用者の同意に基づいて認可するための仕様です。
すべてのデータを無制限に共有するのではなく、
アプリごとに「どの情報にアクセスできるか」を制御することができます！
データアクセスの制御をする際はスコープ（scope）を設定して行います。スコープは、OAuthでアプリがリクエストできるデータの範囲を決める設定です。
例えば、Googleのソーシャルログインでは、以下のように情報を取得することができます。
{
Given_Name:'taro'
Family_Name:'yamda'
Email:'test@example.com'
}
という感じでOAuthを用いてユーザの情報を取得することができます。生年月日やGoogleカレンダーの予定はログイン先のサービスには共有されません。
大まかな流れは以下図のようになっております。
アプリがOAuthを通じてデータへアクセスする場合、ユーザは「このアプリに〇〇の権限を与えますか？」と確認されます。許可しなければ、アプリはそのデータにアクセスできません。
OAuthのスコープ設定によって、特定のデータにアクセスする許可を求めているからなんですね。
また、このようにしてユーザのデータ共有は防がれていたわけですね！
3. 処理の流れってどうなっているの？
ソーシャルログインについてたくさん調べ、何となく理解をすることができたところで、プロトタイプの実装に入りました。
ソーシャルログインの実装方法はインターネット上にたくさん載っていて、どの記事も簡単そうに書かれているので、「簡単にできるんじゃね？」と淡い期待を抱いて実装に取り掛かったんですが、全然うまく進めることができませんでした...。
一般的なログイン処理方式は、IDとPasswordを用いた方式が主流ですがソーシャルログインでは OIDC（OpenID Connect） という仕組みが使われており、その仕組みを理解するのが大変でした。
そこで、実装時に自分がつまずいたポイントも交えながら、ソーシャルログインの処理の流れについてまとめたいと思います。
OIDCとは
サービス間で、利用者の同意に基づきID情報を流通するための標準仕様です。利用者がOpenID提供サイトに登録したID情報を使って、ほかのOpenID対応サイトにログインすることが可能になります。
OpenID Connect｜セキュリティ用語解説｜NRIセキュア
と、書かれていますが、初学者の自分はなんとなく、OIDCは「IDを共有し他サービスへログイン可能にする技術」なんだなぁと、イメージをもって実装に入りました。
そこから、実際に自分で手を動かして実装を進めていくうちに、OIDCをだんだんと理解することができたので、自分なりに処理の流れをまとめたいと思います。
ソーシャルログインフロー
①SNSログイン
まず、ユーザが各種SNSのログインボタンをクリックします。
要は、「Googleのログイン画面に移動したい！」と各種SNSにリクエストしているわけですね！
②認可コード発行
各種SNSが用意してくれたログインページにログイン後、認可コードを発行しクライアントにリダイレクトします。ここから小難しい用語が出てくるので確認をしたいと思います。
認可コード：ID・アクセストークン取得に使うコード
IDトークン：ユーザ情報を含み、本人確認に使う
アクセストークン：各種SNSのAPIにアクセスするための鍵
ユーザ情報(ID・アクセストークン)を取得するために、許可書(認可コード)を発行してもらっているわけですね。
③認可コードの送信
各種SNSから発行してもらった認可コードをここでアプリケーションに送信します。
余談ですが、自分は最初認可コードは「クライントを挟まずに直接アプリケーションへ送信する」という誤った考えのもと実装を進めており、つまづいてしまいました...。
一つ一つの処理手順を理解・確認して実装に入らないと思わぬところでつまづいてしまうので、今後も気を付けていきたいと思います。
④認可コード送信
認可コードを送信し、各種SNSがユーザの存在確認を行います。ユーザが存在したらID・アクセストークンを発行しアプリケーションが受け取ります。
⑤ID・アクセストークン発行
各種SNSからユーザ情報(ID・アクセストークン)をアプリケーションが受け取り、アプリケーションがユーザ認証を行います。
⑥返却
アプリケーションで認証が完了したら、クライアントに向けてユーザ情報を返します。これで、ログイン後の画面に接続を行うことが可能です！
上記の流れだと簡単に実装できそうですが、実際には思い通りにいかないことが多く、特に⑤のユーザ認証の処理を実装するのが大変でした...。
アプリケーション側の実装は、フロントの実装に比べて視覚的にエラー原因の追究を行うことが難しいので、なかなかエラー原因の追究をすることができず苦労しました。
自分の実装したい処理の全体像を把握し、ログを仕込んで自分がどこまで実装できるのか地道に確認を行いながら進めてなんとか実装完了させることができました...。
ただ、普段何気なく使っていた技術を掘り下げて仕組みを理解するのは、SEとして興味深い体験でした！
4. おまけ(今後の期待)
ソーシャルログインについて調べていく中で、今後どのように活用できるかを考えました。その中で、ホテルのチェックイン・チェックアウト作業にソーシャルログインを用いることで、スムーズに行えるのではないかと思いました。
ホテルのチェックイン時に求められる情報の多くは氏名や年齢、生年月日などですが、OAuthのスコープを適切に設定すれば、各種SNS（Google、Yahoo、LINEなど）から取得できるものがほとんどです。
この仕組みを活用すれば、ゲストはホテルのアプリやウェブサイトでソーシャルログインをするだけで、必要な情報を事前に提供でき、フロントでの手続きを大幅に省略できるのではないかと考えました。また、QRコードやデジタルキーを併用すれば、到着後すぐに部屋へ入ることも可能になります。
さらに、チェックアウトもオンラインで完結できれば、フロントに立ち寄る必要がなくると考えました。
もちろん停電、火災、ネットワークのトラブル等含め、たくさんの課題があると思いますが、このような仕組みが広がれば、ホテル側の業務負担が減り、ゲストにとってもストレスのない宿泊体験を提供が実現可能だと思いました。
5. まとめ
ソーシャルログインを調査・実装する過程で、OAuthのスコープによるデータ制御や認証フローを整理できました。
アプリエンジニアとして、ログイン処理の仕組みを理解するのは大事なことなので、1年目のうちにソーシャルログインを学べたのはすごく良い経験になりました。
これからは、パスキーやデジタル認証など、さらに新しい技術にも触れていきたいと思います。
最後まで読んでいただき、ありがとうございました！
