開発基盤部会 Blog

開発基盤部会 Blog >> 記事詳細

2018/06/25

OAuth2 / OpenID Connect課題解決 備忘録 6

Tweet ThisSend to Facebook | by:nishino
 前回に続き、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の利用を止めて、「プロンプト方式」と言うものに移行しつつあるようです。なお「プロンプト方式」はあくまで二要素認証用で、リンクなどを送る用途ではないようです。

 結局の所、同様に、セキュリティ要件に合わせて、これらのプロファイルを決定する必要があります。
09:00 | 投票する | 投票数(0) | コメント(0)