はじめに
本記事はBASE アドベントカレンダー 2023の14日目の記事です。
こんにちは！NEW Dept/Pay ID Dev/Web Backendエンジニアをしている@zanです。
主にPay IDの機能開発を担当しています。
SMS OTPで用いられるメッセージの形式を題材に、
どのような経緯で形式が決まったかを調べてみました。（ちょっとした考古学？みたいなものです。）
SMS OTPとは
SMS OTPと関連技術について振り返ってみましょう。
...と思いましたが、
過去@gatchan0807が書いた今度は「WebOTP」についてFrontend Weekly LT（社内勉強会）でお話しました に詳しく書かれているので、気になる方はご一読いただけると幸いです。 （※2021年の記事なので一部情報が古くなっている可能性があります。）
簡単に言ってしまうと
- SMS OTP = 指定の電話番号にSMSを使ってOTPを送信する
- 関連技術 = WebOTP API, autocomplete="one-time-code" ...etc
です…!
SMSの形式
さて、本題のSMS OTPで用いられるメッセージの形式です。
Origin-bound one-time codes delivered via SMS#authoring によると
In the following origin-bound one-time code message, the top-level host is "example.com", the code is "747723", no embedded host is specified, and the explanatory text is "747723 is your ExampleCo authentication code.\\n\\n". "747723 is your ExampleCo authentication code. @example.com #747723"
と定義されていますね。
実際にSMSに@example.com #747723形式で送信されてきたメッセージを見たことがある方も多いと思います。
また、 Enabling AutoFill for domain-bound SMS codes でも同様に
Your Example code is 123456. @example.com #123456
と定義されていますね。
ここらへんは形式が統一されているようです。
クロスオリジンのiframeはどうなる？
では、クロスオリジンのiframeのなどの場合のメッセージの形式はどうなるのでしょうか？
あまりユースケースがないのかもしれませんが、
WebOTP API やSafariでは、クロスオリジンのiframeでのSMS OTPの入力をサポートしています。
前述のメッセージの形式と異なるので、それぞれ見ていきましょう。
Origin-bound one-time codes delivered via SMS#authoring では、
In the following origin-bound one-time code message, the top-level host is "example.com", the code is "747723", the embedded host is "ecommerce.example", and the explanatory text is "747723 is your ExampleCo authentication code.\\n\\n". "747723 is your ExampleCo authentication code. @example.com #747723 @ecommerce.example"
と定義されています。
一方、 Enabling AutoFill for domain-bound SMS codes では、
Your Example code is 123456. @example.com #123456 %iframe-auth.example.org
と定義されています。
あれ、と思ったかたもいるかもしれません...!
よくよく見てみると、微妙に形式が違います。
@example.com #747723 @ecommerce.example
@example.com #123456 %iframe-auth.example.org
気づきましたね...!
embedded hostが@か%かの違いです。(typoではありません...!)
なぜこの形式になったのか時系列で整理してみた。
なぜこのような違いがあるか疑問に思ったので、時系列で整理してみました。
Apr 30, 2020
Third-party authentication / nested iframes #4を見てみると
元々はクロスオリジンのiframeをサポートする思想ではなかったようです。
（むしろ、意図的に無視していたようです。）
August 4, 2020
Enhance SMS-delivered code security with domain-bound codes の提供開始。
このときはクロスオリジンのiframeに関する記述はありませんね。
123456 is your Example code. @example.com #123456
との記載があるように@example.com #123456形式のみのようです。
Oct 16, 2020
https://github.com/WICG/sms-one-time-codes/issues/4#issuecomment-709557866
この時点で既にクロスオリジンのiframeをサポートするためにembedded hostに%形式を用いていたことがわかります。
議論が再燃して、embedded hostに%形式を採用するかなど、議論がなされていました。
他にも@top #code %iframe or @top #code @iframe or @top @iframe #codeなどなど...。
Mar 24, 2021
https://github.com/WICG/sms-one-time-codes/pull/5
最終的に@example.com #747723 @ecommerce.example形式でマージされたようです。
Dec 13, 2023(※執筆時点)
Enabling AutoFill for domain-bound SMS codesによると
@example.com #123456 %iframe-auth.example.org形式がいまだに使われています。
ほうほう...。
紆余曲折経て、最終的に@example.com #747723 @ecommerce.exampleに着地したことがわかり面白いですね。
そして先駆者はembedded hostに%形式を採用しつづけていると...。
つまり、紆余曲折あって
@example.com #747723 @ecommerce.example
@example.com #123456 %iframe-auth.example.org
に分かれたわけですね。
さて実動作はどうなのか。
気になるところ実動作はどうなのか、というところです。
実動作を見てみるか、と思って調べてみるとブラウザ/OSの違いでそもそもお困りの方が多いようです。
ですので、調査結果はまた別の記事にしたいと思います。(iOS + Chromeェ...。)
(また、いろいろ整理できたので、個人的にも議論に参戦してみたいな、とも思いました。)
- Domain bound SMS Otp autofill not working in WKWebView (but does in Safari)
- Format is inconsistent with iOS docs #18
まとめ
SMS OTPで用いられるメッセージの形式の考古学をしてみました。
こう見てみると、どのような目的があって、今の形式になったのかがわかって面白いですね。
フォーマットや形式はbikeshedな議論になりやすい文脈かと思いますが、最終的な着地点が気持ちいいですね。
何気なく使っている技術も深掘りしてみると面白いものですね。
明日は @TakeuchiSho さんの記事です！お楽しみに。
