去る11月8日に、ドイツ・ベルリンで行われた「APIDays Berlin 2017: Banking APIs and PSD2 — The finish line for PSD2 and Open Banking」で講演を行ってきました。
その時のスライドです。
セッション中幾つかの質問が出てきました。
Q.1 codeとstateを保護することの意味は?
A.1 RFC6749では、認可サーバーは認可応答としてcodeとstateを返します。この返答を改変から保護するには、これらに署名を施す必要があります。分離署名(detatched signature)はこれらのパラメータの値のハッシュをペイロードに入れ、署名を作成し、これらを返答と一緒に送ることに実現します。この分離署名のことを ID Tokenと呼びます。名前はあまり良くないのですが、仕方ありませんね。
Q.2 どうしてstateを保護する必要があるのか？受け取ったstateを送ったものと比較するので十分ではないか？
A.2 攻撃者は、自分のブラウザ・セッション内でcodeとID Tokenを同時に置き換え、自分のstateはそのまま利用するということができます。この場合、stateを比較しても検出できません。そのため、stateとcodeをID Tokenの中で結びつけて署名し、応答に対する分離署名として添付することが必要になるのです。
Q.3 私の作ったアプリケーションはResource Owner Password Credentials Grantを使っています。ビジネスサイドを説得できなかったからです。実際は何を使うべきだったのでしょうか？
A.3 Resource Owner Password Credentials Grantは非推奨です。使うべきではありません。認可サーバーとクライアントが同じセキュリティドメインに属しているのであればまだ許容されますが、フィッシングを促進するので利用するべきではありません。もしあなたが認可サーバーを制御下においているのならば、あなたはIn-App browser tab [RFC8252] のルック・アンド・フィールを完全に制御して、Resource Owner Password Credentialsを使った場合と同じユーザー・インターフェースを実現できるはずです。そして、そうすることによって、２つの独立のセキュリティ・コンテキストを持つことができるようになります。これによってEBAの要求も満たすことができるようになるでしょう。また、もし認可サーバーが第三者のものであるならば、Resource Owner Password Credentialsを使うということは「善意のフィッシング」を行っていることになり、認可サーバーが耐フィッシング・クレデンシャルを導入した瞬間に動かなくなります。