🐥

ソーシャルログインに利用される IDプロバイダの OpenID Connect の対応の違い

masaki

2024/07/11に公開

OAuth 2

OIDC

tech

masaki です。
弊社では LINE や Yahoo! JAPAN などの IDプロバイダのアカウント情報を利用して Web サイトやアプリにソーシャルログインする機能を導入できるサービス「ソーシャルPLUS」を提供しています。
その中で最も利用が多く企業に導入されたのが LINE、Yahoo! JAPAN、Google、Apple でした。

今日は上記プロバイダの OpenID Connect の対応の違いについてまとめてみたいと思います。

この記事の対象者

OAuth2.0 と OpenID Connect について知見がある
IDプロバイダごとにどんな違いがあるのかざっくり知りたい

OpenID Connect の概要

各プロバイダについて見ていく前に、OpneID Connect について概要を記載します。

OpenID Connect は OAuth2.0 を拡張したプロトコルです。
OAuth2.0 は、第三者に対してリソースへの限定的なアクセス権を委譲する認可のためのプロトコルで、RFC6749 および RFC6750 で策定されました。
OAuth2.0 は「認証」ではなく「認可」のため、というところがポイントです。
OAuth2.0 では、Webアプリなどのサービス提供者から見て、フローの途中で取得できる情報が認証されたエンドユーザーの情報であるという保証がありません。
そこで、認証まで拡張したのが OpenID Connect です。
OpenID Connect ではフローの途中で取得できる ID トークンにより、Web アプリなどのサービス提供者はエンドユーザーの認証を行うことができます。

OAuth2.0 は異なるシナリオに対応するために大きく以下３種類の認可フローがあります。

認可コードフロー
インプリシットフロー
ハイブリッドフロー

OpenID Connect は OAuth2.0 のフローを拡張し、IDトークンの取得を追加して、ユーザーの認証情報を安全かつ効率的に取得し、ユーザーのアイデンティティを保証します。
これにより、OAuth2.0 の認証フローが持つ柔軟性を活かしつつ、セキュアな認証および認可を実現します。

認可コードフロー

認可コードフローは主にバックエンドサーバー向けのフローです。
エンドユーザーが認証後、認可コードとよばれるトークンを取得できます。
その認可コードを用いてサーバー側でアクセストークンおよび ID トークンを取得することにより実現するフローです。

インプリシットフロー

インプリシットフローはフロントエンドアプリやネイティブアプリ向けのフローです。
ステップが少なく、迅速な応答が求められる場合に使用されます。
ユーザー認証後、リダイレクトされた URL のフラグメントなどに ID トークンが含まれるため、サーバー側で処理する必要はなく、フロントエンドだけで処理を完結できます。

ハイブリッドフロー

ハイブリッドフローは、認可コードフローとインプリシットフローの利点を組み合わせたフローです。
このフローでは、フロントエンドアプリなどでトークン（アクセストークンおよびIDトークン）を取得し、バックエンドサーバーで別のトークンを取得します。
フロントエンドアプリで取得できる情報を制限することにより処理を迅速に行いつつ、セキュアな情報はバックエンドサーバーで取得することで、処理の迅速化とセキュアさを実現します。

各ID プロバイダの対応の違い

それでは、各ID プロバイダでのサポートしているフローやその他の違いなどについて見ていきます。

LINE

サポートしているフロー：認可コードフロー
スコープ：openid、profile、email
OpenID Configuration：https://access.line.me/.well-known/openid-configuration
ドキュメント

認可エンドポイントには OpenID Connect Core 1.0 で定義されている max_age や ui_locales をリクエスト時に設定できます。
また、bot_prompt や initial_amr_display など独自のパラメータが多く存在します。
scope の email は LINE 社に対して取得権限を申請する必要があります。

ID トークンには name、picture（プロフィールの画像URL）、email といったユーザーの属性情報が含まれます。
気をつけるところは、IDトークンの署名アルゴリズムが、Webログインとネイティブアプリ・LINE SDK・LIFFアプリで異なる点です。
Webログインの場合の署名アルゴリズムは HS256 で、検証時には LINE のログインチャネルのシークレット情報を使う、もしくは検証用の LINE の Web API を利用します。
ID トークンに含まれるエンドユーザーの識別子はクライアントごと（LINE デベロッパー画面ではプロバイダと呼ぶ）に異なります。

Yahoo! JAPAN

サポートしているフロー：認可コードフロー、インプリシットフロー、ハイブリッドフロー
スコープ：openid、profile、email、address
OpenID Configuration：https://auth.login.yahoo.co.jp/yconnect/v2/.well-known/openid-configuration
ドキュメント

認可コードフローだけでなく、インプリシットフローやハイブリッドフローにも対応しています。
認可エンドポイントのリクエストパラメータはシンプルで、プロバイダ固有のパラメータは多くありません。

ID トークンのペイロードにはユーザーの属性情報が含まれていないため、属性情報が必要な場合はユーザー情報エンドポイントから取得する必要があります。
ID トークンの署名アルゴリズムは RS256 で、検証は JWKsエンドポイントもしくは Public Keysエンドポイントから必要なキーを取得し、検証を行います。
ドキュメントがすっきりしており、とても分かりやすいのが印象的でした。

Google

サポートしているフロー：認可コードフロー、インプリシットフロー、ハイブリッドフロー
スコープ：openid、email、profile
OpenID Configuration：https://accounts.google.com/.well-known/openid-configuration
ドキュメント
- Google Identity Platform
- Authentication URI parameters

Yahoo! JAPAN と同じく認可コードフローだけでなく、インプリシットフローやハイブリッドフローにも対応しています。
認可エンドポイントのパラメータには access_type、display、include_granted_scopes、login_hint、prompt など多くのプロバイダ固有のものをリクエストできます。

ID トークンのペイロードには email、name、locale、picture（プロフィール画像URL）、profile（プロフィールページURL）など、さまざまなユーザーの属性情報が含まれています。
ID トークンの署名アルゴリズムは RS256 であり、検証は JWKsエンドポイントから取得した情報を用いて行います。
若干ドキュメントが分かりづらい印象でした。

Apple

サポートしているフロー：認可コードフロー
スコープ：openid、email、name
OpenID Configuration：https://appleid.apple.com/.well-known/openid-configuration
ドキュメント

認可コードフローのみ対応しています。
認可エンドポイントに設定するスコープについて、OpenID Configuration では openid が含まれていますが、ドキュメント上では name と email のみとなっています。
実際のリクエストでも、openid を含めずに ID トークンを取得することが可能となっていますが、openid を含めても含めなくても同じ結果になります。
また、response_mode パラメータで、エンドユーザーの認可後のレスポンス方法を指定することができますが、response_type に id_token を指定した場合、response_mode は必ず form_post を指定する必要があります。
form_post がどのような動作をするかというと、エンドユーザーの認可後にフォームタグを含む HTML コードレンダリングが行われ、HTML に組み込まれた JavaScript コードによってフォームがサブミットされ、認可エンドポイントに指定したリダイレクトURL に POST リクエストされ、認可コードや ID トークンを取得できる、という仕組みになっています。

OAuth 2.0 Form Post Response Mode

ID トークンのペイロードのユーザーの属性情報には email のみが含まれています。
また、email はプロキシアドレスの場合があります。
ID トークンの署名アルゴリズムは RS256 で、検証は JWKsエンドポイントから取得したキーを用いて検証を行います。

ユーザー情報を取得するエンドポイントは、公式では存在していません。
しかし認可エンドポイントの scope には name を指定できます。
name をどこで取得するかと言うと、認可後に POST リクエストで受信するボディに含まれています。
リクエストボディの ID トークンなどと合わせて user というパラメータから取得できるようになっています。
他のプロバイダと比較してかなり独自な実装をしている印象です。

まとめ

主要なソーシャルメディアの OpenID Connect の対応の違いをまとめてみました。
以下は各 ID プロバイダのざっくりした印象です。

LINE：独自パラメータが多く、オプションが豊富
Yahoo! JAPAN：OpenID Connect の仕様に忠実で扱いやすい
Google：Yahoo! JAPAN と同じ印象
Apple：独自実装が多く、難易度が高い

以上、参考になれば幸いです。
もし間違ったところなどあればコメント頂けると嬉しいです。

SocialPLUS Tech BlogPublication

株式会社ソーシャルPLUS 開発チームの技術ブログです。