134 views
B!0X

Auth0の`403: User to be acted on does not match subject in bearer token.`にハマった話

auth0-403-user-to-be-acted-on-does-not-match-subject-in-bearer-token

背景

  • auth0のmanagement apiにアクセスするためのclient applicationを作成してそこからアクセスしようと思っていた
  • auth0の設定・構築自体はすべてterraformで行っている
  • client application自体はpythonのauth0 sdkを使用してアクセスしようとしていた
  • すると以下の様なエラーが出で解決に苦労したのでメモ
403: User to be acted on does not match subject in bearer token.

エラーが出ていた現象

  • 叩こうとしていたapiはget a user api
  • management api tokenの取得などはすべて正常に行えていて、実際のapi callの結果として前述のレスポンスが返っていた

解決策

  • 以下をすべて行う

1. clientのapp_type=non_interactiveに設定する

  • terraformのauth0_clientresourceではapp_typeを指定できる
  • これを non_interactive で指定しないといわゆるM2Mアプリケーションにならないっぽい
  • これがなくてもAPIは叩けるっぽいが、多分やったほうが良い

2. 余計なscopeを削る

image

  • get a user apiではscopesとして複数挙げられているが、これを全部設定しなくて良い
  • というか全部設定しているとauth0が内部的にM2Mにとっては余計なsubの検証などを行い、最初のエラーにつながるっぽい

image

  • 確かにスコープはいずれかを指定していれば良いとある

スクリーンショット 2023-10-14 15.11.41

  • そもそもmanagement apiのpermissionsでは指定しないほうがよいpermissionは挙げられていないので、指定できないようになっている
  • 今回はすべてterraformで構築していたことにより、permission文字列を直指定できてしまったことが事故に繋がったっぽい
  • なのでterraformでもpermission文字列としてここから見れるものだけを指定するのが良さそう

参考

関連事例

  • セキュリティ診断・対策

    事例:基盤システムのセキュリティ常時監視と対策

    人材サービスの会社は専門の人材を採用せずに、自社のシステムの安全の状態を把握できるようになりました。同社は業務の基盤システムを開発会社に発注しており、社内にエンジニアはいません。開発支援会社の KDOT はこの開発会社の下で開発に参加し、クラウドの状態を仕組みで常に自動点検する常時監視を、機能の開発と並行して導入しました。そのうえで常時監視が検出した 200件を超える指摘に対応し、件数と対応の計画を開発会社経由で同社に報告しました。監視と対応は現在も KDOT の担当です。

  • データ分析支援

    事例:過去実績を提案に活用する分析の仕組み

    広告代理店との取り組みです。同社は過去実績の示唆を次の提案へ反映し、結果をどのように予測したか、その背景まで提案先のクライアントへ説明できるようになりました。KDOT は案ごとの見込みと判断材料を比較できる仕組みを業務アプリとして実装しました。さらに業務アプリの中核となる処理ロジックと機械学習モデルについて、特許手続きを担う弁理士が技術の新規性や工夫を検討するための資料を作成しました。その後この発明には特許が付与されました。

開発の相談先をお探しですか。

この記事に関わることについてご相談がある方はお問い合わせください。

KDOT についてお問い合わせ