Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

組織内でのAPI認証にOAuth2 Client Credential flowを使うメリット募集

内閣官房が政府CIOポータルで公開してる標準ガイドライン群では、APIテクニカルガイドブックで、API認証をする際は「APIキー又はOpenID Connect」による認証を推奨しています。

ただ、調達の受注者としては「政府CIOポータルで推奨されている方式に従いました」というだけでは、「ベンダーが余計な仕様を追加して値増しを狙ってきたぞ」と思われかねません。「このような脅威が想定されるので、それに対してこうします」が筋なわけです。脅威の明確化をしましょう、とNIST SP800-18とかにも書かれてます。

組織間システム連携用のAPIなんかを設計する場合、

  • リソースサーバとIdPが上位組織(本社システムとか)、RPが下位組織(支社システムとか)にある
  • IdPはこのAPI専用
  • システム連携用のAPIだから、クライアントIDとシークレットはAPサーバの上にあって、人間が参照することはほとんどない
  • クライアントIDとシークレットを使うのは限られた職員のみ(不特定多数ではない)
  • 上位組織と下位組織の間の通信は、専用線またはTLSで保護されている

みたいな状況だと、「それってわざわざIdPにTokenもらいに行く必要あるの?Basic認証でユーザID+パスワードで認証するみたいに、クライアントIDとシークレットのみで認証すればよいのでは?」という疑問が上がることがあるわけです。

もちろん、認証処理を任せられるライブラリがあるから開発が楽チン、みたいな評価項目もあります。ただそれとは別に、セキュリティ上のメリットがないか調べていたところ、以下のQ&Aが見つかりました。

stackoverflow.com

  1. シークレットがAPI呼出の度に送られなくなる。トークンには有効期限(たとえば15分)が付いているから、MITMなどでトークンが漏洩しても15分後には無効になる。
  2. トークンに認可のスコープ情報などを付けて返せる
  3. トークンが正当か、いちいちIdPに問い合わせなくても、リソースサーバで検証できる(トークンの署名などのことと思われる)ので性能面で有利

といった点が挙げられてます。

状況にもよりますが、1.は専用線なら構内に入られた時点でOAuth2を使ってようがやりたい放題だし、2.はIdPがこのAPI専用だから関係なし、3.はRPが認証時にJSESSIONIDを発行するのと同じで済むのでは……と考えると、いずれもメリットにはならない気がします。