こんばんは、ritouです。
まだNatさんのチャンネルをサブスクライブしていないの？
前の記事 : 文字で読みたい2分間OAuth講座 : (5) Secret of Authorization Code, (6) Actors of OAuth - r-weblife
では、今回も見ていきましょう。
(7) When can one use password grant?
今回は、Resource Owner Password Credentials Grant Type (ROPC) の使い所について説明します。 一言で言うと「使ってはいけません」なのですが、それだと2分間にならないのでもう少し説明します。
ROPCは、ユーザー(Resource Owner) が自らのIdentifier, パスワードを Client に渡し、 Client はそれを Authorization Server に渡して Access Token を取得するフローです。
UIで言うと、これらはユーザー認証にあたりバックエンドのLDAPやDBサーバーに問い合わせる、(OAuthが登場する前からある)レガシーなアプリケーションと同様です。
仕組みとしてレガシーアプリケーションよりもROPCで改善されている点としては、Client が Resource Owner のパスワードを保存することなく、タスクを実行できることです。
しかし、ここでClient は"中間者"としていわゆる"中間者攻撃"を行なっていることに注意すべきです。
Client は Resource Owner のパスワードを取得しているので、Resource Owner ができることは Resource Owner に成り代わって全てできます。 (Authorization Server が Resource Owner に対して Client からの要求に対する許可を問い合わせる Authorization Code Grant とは異なり、) Resource Owner が実際に許可を与えたかどうかを Authorization Server はわかりません。
Authorization Server が Client に全幅の信頼を寄せていても、これはしても良い事ではありません。 なぜなら、Resource Owner をフィッシング攻撃に脆弱になるように訓練しているようなものだからです。 ある意味では、これはインターネットに公害を垂れ流し、他人にコストを押し付けていることになります。
悪いことは他にもいくつかありますが... Scott Brady さんの記事は、この件に関する良い概論となっています。
せっかくなので目次だけでもざっと載せると、
- ROPCがなぜ存在するのか
- ROPCを使うべきではないたったn個の理由
- ROPCを使う前の自分自身への4つの質問
が書いてあり、まとめとしては
- (著者が)唯一 ROPC の利用を認めたのは、2000年前半のレガシーアプリケーションからの移行の時だけ
- ブラウザベースのクライアントアプリケーションなら Implicit Grant使え
- WebアプリケーションならAuthorization Code Grant使え
- IoTデバイスなら Device Flow使え
とのことです。
If you use this grant type despite the above, I will be nasty to you and say mean things about you both behind your back and to your face.
"say mean things about" は意地悪なことを言うって意味ですな。 say mean things a...の意味・用例｜英辞郎 on the WEB：アルク 何やら穏やかではない。
んで、最後にこの動画が貼り付けられています。循環参照的な...
話を戻します。 もしモバイルアプリケーションを書いているならば、IETF BCP212 が参考になります。
BCP 212 - OAuth 2.0 for Native Apps
まとめると、
- ROPC は Resource Owner のパスワードを扱うフローであり、推奨されていない
- RFC6749に記載されているのも、レガシーアプリケーションからの移行が理由である。もう7年前だぞ。
- 要するに、使うな
そして、第8回はそれでも食い下がって来る人向けのお話のようです。
(8) ROPC (Password Grant) the Migration Tool
前回、ROPC使うなって言ったら、仕様に書いてるから使っていいだろって言われました。 ほんとかどうか見ていきましょう。
ROPC は RFC6749 に記載されていますが、こうも書かれています。
The authorization server and client SHOULD minimize use of this grant type and utilize other grant types whenever possible. Authorization Server と Client はこのフローの利用を最小限とするべきで、可能な限り他のフローを使うべき
なので、一言で言うと、「使うな」と言うことです。 では、なぜ記載されているのか。ROPC の使い所が一つだけあります。 それは、「パスワードを扱うレガシーな Client の OAuth 2.0移行」のためです。
今回は、その移行方法について説明します。
まず、パスワードを保存しているレガシーなアプリケーションがあります。
まず、ROPCのフローを実装してアプリケーションを更新します。
Client は保存してあるパスワードを Authorization Server に送り、Access Tokenを取得します。
保存してあるパスワードは削除。
代わりにAccess Tokenを保存します。
これで、裏側はAccess Tokenをベースでデータをやり取りする、OAuth 2.0 の Client に移行できました。 これだけであれば、ユーザーにパスワード入れなおしてもらわなくてもできます。"Zero Friction Migration!!!"
裏側はAccess Tokenベースになっているので、後はアプリケーションの特性に合わせて Access Token 取得までのフローを改修してやれば良いです。
まとめると、
- ROPCがRFC6749に記載されている理由は、レガシーアプリケーションからの移行のためである
- パスワードを保存しているレガシーアプリケーションは、ROPCで Access Token に変換して保存することで
- 保存してあるパスワードでごにょごにょやるのでユーザーにパスワード聞き直す必要もない
- このケースじゃない場合、別のフローを使うこと考えなさい
と言う感じですね。
これで9/26時点で最新の第8回に追いつきました。 これからできることは、チャンネルをサブスクリプションして動画を再生し、Natさんのモチベーションを上げることです。
ではまた。
