おはようございます、ritou です。
様々なご都合によりGitHubでTwo-factor authenticationってのを設定している方も多いでしょう。
時に人間は、記憶もスマホも財布も一気に無くしてしまいます。
リカバリー方法を複数用意しておくにこしたことはありません。
2019年7月時点の設定画面あたりのスクショはこんな感じです。
今回はこの中のRecovery optionsの一番下、「Recovery tokens」に注目します。
これ何だ？と思ってカーソルを当てると「Account recovery with Facebook is a simple way to recover your account.」とか出てきます。
今回はこの「Facebookでアカウントリカバリー」とは何かというお話です。
GitHub の機能を使ってみる
GitHubのヘルプに全部書いてあります。
- リカバリーの設定について Configuring two-factor authentication recovery methods - GitHub Help / Adding a fallback authentication method with Recover Accounts Elsewhere
- リカバリーの実行方法について Recovering your account if you lose your 2FA credentials - GitHub Help / Authenticating with an account recovery token
これで満足していただけるようであればそれで良いと思いますが、一応書いてある通りやってみます。
リカバリーの設定
GitHubにて「Settings」->「Security」->「Two-factor authentication」->「Recovery tokens」と進みます。
この機能では 「お前のデータにアクセスはしないけど、こっちのサポートチームがお前のIdentityを検証するために使える。」 「まずはfacebook行って来い」 てなことが書いてあります。
Facebookに行ってみると何かの確認画面が出てきますが、いつものアクセス許可への同意画面とは何か少し違います。
「詳しくはこちら」の先も確認しましょう。
「いかがでしたでしょうか？」でまとめてくるブログ記事みたいな雰囲気のタイトルがついたヘルプページですが、基本的にデータはシェアされないことが書いてあります。
オンにすると設定完了です。
Githubに戻ってきました。
リカバリーの実行
GitHubを一旦ログアウトして、Facebookからリカバリーする手順を踏んでみましょう。
今度はFacebook側で「設定」->「セキュリティとログイン」->「外部アカウントのリカバリー」と進みます。
GitHubの設定があることがわかります。
リカバリーしてみます
(ここは人によりそうですが、私は2段階認証でSMSを設定しているせいか、確認が入りました。)
GitHubに遷移して...こんなメッセージが出てきました。
一発でログインさせるのではなく、サポートチームに「Facebookのリカバリートークン使った復活をお願いします」と問い合わせてやってもらう流れです。
(おまけ)ちなみにもう一回試そうと思ったらこんなんなりました。
終 制作・著作 ━━━━━ ⓡⓘⓣⓞⓤ
この仕組み、標準化されたものではなくFacebookの独自のものです。Facebook側のドキュメントを見て仕組みを理解しましょう。
Facebookの仕様を理解する
ここですね。
クローズドβということですが、GitHub以外に使ってるとこあるんでしょうか？なさそう？
概要
概要としては
- パスワードや連絡先を失った場合のリカバリーに利用可能
- OAuth/OIDCを用いたソーシャルログインとは異なり、ユーザー情報を共有しないシンプルな仕組み
- メールやSMSへのコード送信よりもセキュア、連絡先変更時のトラブル回避にも使える
とあります。(私の場合、SMSの確認が入ったので若干気になるところもありますがこの辺は設定次第かもしれません。) 用途についても書いてますがとりあえずリカバリーです。
処理の流れ
登場人物は3者です。
- Account Provider : Delegated Account Recoveryを利用するサービス (GitHub)
- Recovery Provider : Delegated Account Recoveryを提供するサービス (Facebook)
- User : GitHub / Facebookの両方にアカウントを持つユーザー
設定手順としては
- UserがAccountProviderにて認証済み or 新規登録中
- UserはAccountProviderにてサポートされているRecoveryProviderを選択
- AccountProviderはRecoveryTokenを生成、Userのブラウザ上でRecoveryProviderに送信 4 RecoveryProviderはUserにRecoveryTokenを紐付けて保存し、AccountProviderに戻る
という4ステップがあり、実行フローも
- Userはリカバリーが必要なことをAccountProviderに伝え、AccountProviderは紐づいているRecoveryProviderにUserをリダイレクト
- UserはRecoveryProviderにて認証される(リカバリ用途だとわかっているので、追加認証を求められる場合もある)
- RecoveryProviderはAccountProviderから受け取って保存していたRecoveryTokenを含むCountersignedTokenを生成し、Userのブラウザ経由でAccountProviderに送る
- AccountProviderはCountersignedTokenがRecoveryProviderからのものであることを検証、RecoveryTokenを検証したら内部のデータを複合化してUserをリカバリーします
という4ステップです。 シーケンスについては上記ページに記載してあります。
技術的なポイントとしては
- 準備
- OAuth/OIDCのClient登録的なものは必要なのか
- 設定
- 実行
- 妄想
- OIDCをシンプルにして同じことできないか
といったあたりが気になりますね。 書いてたらとても長くなって諦めたので、次回プロトコル編として公開したいと思います。
ではまた！
