メールソフトで考えるリソースアクセスとOAuth
ritouです。
OAuth認証やOAuthログインなんて言うのは平成で終わりにしないといけなかったんですが、そううまくはいかないようです。
メールソフトのやっていること
メーラーとかメールソフトのやることといえば
- メール関連の処理を行う
のがメインですね。
他に色々できるやつもあるのかもしれませんが 置いときます 。
メールソフトにログインする訳ではなく、対象メールアカウントへのアクセス権限が欲しいだけです。
ここは昔からなんとなく理解しやすい気がする。しない?これこそリソースアクセスですよね。
ずっと前から、メールソフトでは、
- メールサーバーを設定することで対象リソースを把握
- ユーザー名、パスワードを設定することでリソースオーナーであることを確認してメールにアクセス
していたわけですね。
この辺りについて意識が高まっていた10年前にブログ記事を書いたことがあったんですが、メールとかカレンダーとかその辺のプロトコルがはこうなってるので仕方ないって感じだった記憶があります。
OAuthがなかった時代にIdPがやったこと
例えばGoogleのようなあれもこれもできるサービスにとって、クレデンシャルを渡すこれまでの方式にはリスクがあるでしょう。
- メールソフトで管理しているクレデンシャルが盗難、漏洩した場合のリスクがでかい
- パスワード変更したらこっちも変えないといけない
- 数年前からユーザー認証方式が複雑化、2FAやパスワードレスといったキーワードとともに多様化してるのにパスワード認証方式だけなのは辛い
いやいや、メールソフト使うのはお前のパソコンとかなんだからそれでいいだろうと思う人もいるでしょう。
とはいえ、Webメールでの設定は手元の端末じゃないところにもありますし、漏洩時などのリスクも抑えられる方がいいでしょう。
と言うことで、Googleさんはメールソフトなどで使えるパスワードを別に払い出せるようにしたこともありました。
アプリパスワードっていうんだったかな。サービスアカウントみたいなやつ。
アプリ パスワードとは、安全性の低いアプリやデバイスに Google アカウントへのアクセスを許可する 16 桁のパスコードです。
安全性の低いアプリやデバイスですって。意識の低いお客様に見たいな言い方、素敵です。
実際はこんな感じで設定できます。
さらにリソースの範囲を制限できると一番良かったんでしょうけども、まぁとりあえず用途別に作れますよって感じですかね。
OAuthとメールソフトの親和性
どこかの団体のエバンジェリストとかが言うには
- クレデンシャル(パスワード)を外部サービスなどに渡さなくて良い
- アクセス対象となるリソースの範囲を細かく制御できる
みたいなのがOAuthの特徴だそうです。
あと、リソースオーナーの同意を得る際の認証方式などはOAuthの仕様の対象外であることも特徴の一つですね。
メールソフトにおいても、OAuthを使うことで
- アクセス対象のリソースをメール機能に限定できる
- 2FAなどを利用するユーザーも設定時に認証強度を下げずにユーザーを確認できる
と言うメリットがあります。
どうやって OAuth でメール関連の処理が行われているのか
そんなこんなで、Googleはいつからかは忘れましたがメールソフトからOAuthで接続できるような機能を提供してきた訳ですね。
裏側で何が使われているかというと、
SAML じゃなくて SASL です。あとはググってくれ。
まとめ
- メールソフトがやってることってリソースアクセスだよね
- リソースアクセスといえばOAuthだよね
- SASLってので実現されてるらしい
- 校長「世の中のメールソフトがOAuth使い始めるまで10年かかりました。」
ではまた。
Discussion