本サイトからスピンオフした姉妹サイトです。2.0は何が違い、何が共通するのかを概説。Connectの主要なユースケースについて、Clientタイプ別と認証パターン別に説明する。2.0を、主要ユースケースごとに、その特徴と注意点についてまとめた。2.0の違い・共通点について見てみよう。1.0に適宜リンクしながら話を進める。2.0のものを使うようにする。Connectの用語対応表を載せておくので、上記翻訳仕様や外部の記事などを読み進める際の参考にしてほしい。Connectという表現が最もふさわしい。2.0の拡張仕様の一つである。1.0/2.0ベースのID連携の仕組みがTwitterやFacebookなどの巨大SNSから提供され、人気を博した。これらの仕組みは今でも広く利用されている。2.0では、ID情報の連携はできるもののAPI連携には利用できないなど、デベロッパーに強く訴求できていない状況であった。Connectである。Loginが良い例であろう。Connectの仕様策定においてもFacebookの実装が強く影響を与えている。Loginのフロー(Flow)をながめながら、ID連携に必要な機能をまとめることにする。Loginは、以下のようなフローになる。Serverが共通なので、前回の記事のWebアプリのケースと登場人物が少し異なるが、本質的には同様である。Client側での認証を行う。Client側でユーザーから直接追加のプロフィール情報を取得してから登録させる場合もある)。Client側でユーザーを認証することになる。2.0を使ったID連携では、以下の2点が必須要件となっている。API)も必要になる。APIの仕様については定めていない」ということである。Connectでは、これらを標準化しているのである。APIというものを定義している。2」に定義されているさまざまな情報を含んでいる。Server上のエンドユーザーの識別子であるsub、Tokenの発行先を示すaud、Tokenの発行者を特定するためのiss、リプレイ攻撃を防ぐために使われるnonce、エンドユーザー認証が行われた時刻を表すauth_timeなどがある。Token(JWT)という方式で署名&エンコードされた、署名付きJSONデータである。JWTのデコードおよび署名検証については、「JWT.io」というサイトに各言語ごとのライブラリがリストアップされているので、それらを使うとよい。Responseに含まれるか、その両方に含まれるかのいずれかになる。Tokenの発行方法)についてまとめる。Endpointから直接発行された場合以外でも発行者(=署名者)を特定できるようにしたりしている。Requestを送信した場合には、リプレイ攻撃を防ぐためにnonceを含めたり、ユーザーが明示的に認証行為(パスワードの入力など)を行った時刻を示すauth_timeを含めたりすることもできる。Requestに含めるmax_ageリクエストパラメーター)である。5.5以降は複雑なユースケースを満たすためのものだが、いったん無視してよい)。Scope値が標準化されたものといえば分かりやすいだろうか。Tokenにプロフィール情報を入れるケースはまれである。3.1.2.1、3.2.2.1、3.3.2.1」に定義されている。Connectのリクエストであることを伝えるための、最も重要なパラメーターである。Connect」といわれるゆえんである。Connectの利用パターンをまとめていこう。「JSアプリ」とは、前回も説明したように「JavaScriptによりブラウザー上で動作するクライアントアプリ」のことで、サーバーサイドで動作する「Webアプリ」とは別タイプのクライアントである。Connectを利用することも基本ない。Connectのコンテキストでは「継続的にAPIにアクセスする」といった要件もない。よってケース2と5の差は特にない。よって本稿ではケース1と3のみを扱う。Codeフローが用いられる。このフローをシーケンスにすると図2のようになる。Loginと同じフローとなることが分かるだろう。Tokenのみで認証が完了できるという点くらいである。APIにアクセスすることが禁じられるものではないが、特にAPIプロバイダー側でのプロフィール情報更新を同期する必要がなければ、不要なAPIアクセスをスキップできた方がパフォーマンスは良い。APIのレスポンスが標準化されていることくらいである。5.4」で定義されているprofile、email、address、phoneというプロフィール情報に関連するScopeを定義している。Tokenの改ざんリスクは無視できる。Token自体の署名検証はOPTIONAL(任意)とされている。Tokenがリプレイ(再利用)される可能性も無視できるため、nonceの利用もOPTIONALとなっている。Tokenをデコードして中に含まれるsub値を基にユーザーを認証するだけである。token)を使う場合があった。token)を利用する場合と比べて複雑になる。tokenをサポートしていない実装はまずないため、必ずと言ってよいほどHybridフローが利用できる。ConnectではHybridフローのみを利用すればよい。3.3」に同時に書かれているため、仕様は多少読みづらいかもしれない。tokenの場合のフローをシーケンスにすると図3のようになる。APIのレスポンスが標準化されていることくらいである。Tokenが発行されるため、署名検証やnonceの利用はOPTIONALである。tokenが利用できれば、主要なユースケースは満たすことができる。Tokenを使うモチベーションもユーザー認証というコンテキストではほぼ存在しない。Tokenは以下のような属性を含むことができ、部分的なレスポンスパラメーターの置換・改ざんを検知するために利用できる。Server上では別のユーザーにひも付いた状態になる。ServerからAPIアクセスした場合で、矛盾した結果が引き起こされることになる。Serverから振込APIを叩いた場合で、異なる口座から振込処理が行われ得る。Tokenを認証目的以外で利用するといったケースもあり得るのである。Writeの2種類あり)などを読んで見るとよいだろう(2017年7月段階では未翻訳)。Connectユースケース一覧(認証パターン別)ID連携の場合には、Clientのタイプ以外にも、いくつかの代表的なユースケースが存在する。Connectの利用方法をまとめる。On(SSO)」と呼ばれるものの一種では、以下の2つの要件を同時に満たしたいというケースがある。Server側のセッション状態を知ることはできない。Client側でログインボタンを表示することはできない。3.1.2.1」参照)。iframeを使うテクニックを紹介したが、あれがまさにこのprompt=noneリクエストパラメーターを利用するケースである。2.0の場合にも利用できることが多い。Server上で認証済みかつ同意済みであっても、強制的に認証をさせたいという場合もある。これは共有PCなどでログアウトし忘れたまま離席した際に、当該マシンを第三者に悪用されるといったリスクに対する対抗策として利用されることが多い。Serverに簡易的に認証/同意画面を強制表示させることができる。Connectのリクエストパラメーターはブラウザー操作者によって改ざん・追加・削除が可能なので、prompt=loginというリクエストパラメーターを削除されてしまっては意味がない。3.1.2.1」参照)。Tokenにauth_timeという属性が含まれて返されるため、この属性の有無およびその時間をチェックすることで、確実に再認証が行われたことが確認できる。Clientがその結果を受け取るまでの若干のタイムラグを許容するよう実装すること。Connectの概要やユースケース毎の使い方について見てきた。Client側の実装者にとっては、この2回の記事でほとんどのユースケースは満たされるものと期待している。Japanに声をかけてほしい。Foundation(Global)にコンタクトしてもよいだろう。Connectライブラリの公開を行っているので、それらのツールもぜひ活用してほしい。2.0の現状と概要を紹介。2.0の各種ユースケースについて、仕様を読み解きながら説明する。2.0は何が違い、何が共通するのかを概説。Connectの主要なユースケースについて、Clientタイプ別と認証パターン別に説明する。機械学習エンジニアを目指す人~初中級者のための技術情報サイトです。「機械学習&AI」「クラウド&ビッグデータ」「IoTデバイス」のネット記事情報を共有中。開発者のためのSlackチーム、作りました:「機械学習&AI」「クラウド&ビッグデータ」「IoTデバイス」のネット記事情報を共有中。2020最適なビューへの切り替えを推奨します:スマートフォン用表示に。