kubell Creator's Note

ビジネスチャット「Chatwork」のエンジニアのブログです。

ビジネスチャット「Chatwork」のエンジニアのブログです。

読者になる

OAuth2 パブリッククライアント対応

かとじゅん(@j5ik2o)です。OAuth2を使った、チャットワークAPI開発者向けのリリース情報です。

以前にPKCE対応を告知させていただきましたが、iOS/Android/JavaScriptなどのパブリッククライアントが直接的にOAuth2クライアントになれませんでした。今回対応でそれが可能になりました。バックエンドのサーバがなくても、スマフォアプリなどがOAuth2クライアントとして運用可能となりました!

creators-note.chatwork.com

以下のようにクライアント登録画面で、パブリッククライアントを指定できるようになりました。

f:id:j5ik2o:20181119152552p:plain

詳しい仕様はAPIドキュメントを参照してください。

クライアントタイプの選び方

従来のコンフィデンシャルクライアントとあわせてどのような判断基準でクライアントタイプを選べばよいか、ユースケースに応じてクライアントタイプの選び方を簡単に解説します。

まず、従来どおりの仕様ですが、APIを利用するアプリケーションがサーバ型である場合は、コンフィデンシャルクライアントを選んでください。このケースの場合は、サーバにクライアントアプリケーションが連携するとしても、OAuth2クライアントになれるのはサーバ上で稼働するサーバアプリケーションのみです。

逆に、APIを利用するアプリケーションがiOS/Android/JavaScriptなどのクライアント型であれば、パブリッククライアントを選んでください。この機能は今回リリースされた機能です。このケースでは、クライアントそのものがOAuth2クライアントとなる ため、サーバは不要です。スマフォファーストでサーバレスなサービスでは便利かもしれません。さらに、パブリッククライアントでは、セキュリティ強化のために以下の制約があります。

  • PKCEが必須となる。
    • 認可リクエスト時にcode_challenge, code_challenge_methodと、トークンエンドポイントの初回アクセス時にcode_verifierが別途必要になります
    • なお、PKCE対応したとしても、アプリケーション自体のなりすましは防止できません。クライアント認証をおこなっているわけではないからです。詳しくは、PKCE で防げる「認可コード横取り攻撃」とはどのような攻撃か - Qiitaの「PKCEを利用しても防げない攻撃」を参照してください。なりすましのリスクを最小化するために各プラットフォームの電子署名の機構を利用するなどの対策が必要です。
  • 永続的なAPIアクセスを可能にする、offline_accessスコープは利用できません

ということで、簡単でありましたが、パブリッククライアント対応のお知らせでした。ぜひ、お試しください! ご不明点・お気づきのことなどがあれば、フィードバックからお問い合わせください。