前回に続き、OAuth2 / OpenID Connect課題解決 備忘録の第6回です。

　今回のテーマは、
　　「SMSからのアクセス時の簡易的な認証方法について。」
　です。

＜要件＞

　SMSに配信したコンテンツ（URL）を認証する方法

＜解決案＞

　OAuth2/OIDC界隈の参考情報になりますが、
　スタンダードな方式は以下かもしれません。

＜リンク押下後に、認証する。＞

・クライアントがWeb
　リンク押下後、OAuth2/OIDC

・クライアントがNative（Hybridも含む）
　リンク押下後、OAuth PKCE

　「ブラウザ記憶なら手打ちはいらないのでUX的に優れる」
というのは、RFCの考慮事項にも書かれています。

＜リンク押下後に、認証しない。＞

・クライアントがWeb
　・RFC7523等のクライアント認証のメカニズムを導入する。
　・FIDO2（WebAuthn）などにより認証処理自体を簡素化する。

・クライアントがNative（Hybridも含む）
　なし（若しくはWeb経由で前述の認証を行う）。

　上記のRFC7523（JWT bearer token authorizationグラント種別）は、予め、クライアント側の秘密鍵（証明書）を生成し、公開鍵をSTS/IdPに登録しておく。そして、認証時に、クライアントを表すJWTを生成して秘密鍵で署名したものをSTS/IdPに送ると、ユーザのアカウント入力など無しに、クライアントを認証（token取得）できる（ただし、Publicクライアントからは利用不可能）という方式です。

＜感想＞

　全体的に、どのようなプロファイルにするか？は、セキュリティ要件によると思います。これは、例えば、金融向けWebAPIに「Financial-API」と言うOAuth2 / OpenID Connect + α の「セキュリティ・プロファイル」が作成されており、参照系・更新系に分けてPart1のプロファイル、Part2のプロファイルが適用される。と言うのに似ています。

＜余談＞

　OneDriveでの共有（編集可）などは、「https://1drv.ms/f/s!XXXXXXXXXX」となります（XXXXXX部分にtoken的なものが入る）。通常は E-mail などでリンクを送っていると思います。これをセキュリ的にSMSで送った場合のセキュリティ・レベルは「？」です。

　また、SMSにも問題があるとのコトで、最近Googleなどでは、二要素認証にSMSの利用を止めて、「プロンプト方式」と言うものに移行しつつあるようです。なお「プロンプト方式」はあくまで二要素認証用で、リンクなどを送る用途ではないようです。

　結局の所、同様に、セキュリティ要件に合わせて、これらのプロファイルを決定する必要があります。