APIトークンでできる範囲と、パスワード認証に関してTwitterで少し議論がありました。
https://twitter.com/m_ando_japan/status/1060303900111060992
セキュリティを考慮するとパスワード認証をむやみに連携プログラムに設定したく無いのですが、現状では仕方なく利用せざるを得ないケースもあるかと思います。どのような対策をされているか、皆さんの意見をお聞きしたいと思い投稿を作ってみました。
私自身は、kintone の良さを活かす意味で凝ったことを諦めるのも一つの答えなのかと思ってます。一方で、もう少しAPIトークンの利便性が上がって欲しいなと。
僕は「仕方なくパスワード認証使っている」派です。
APIトークン認証で可能な操作がかなり限られている理由が正直わかりません。
重要度の高い操作ほどAPIトークン使えないのですが、なぜなんでしょうね？
まず理由が知りたいです。
「新しいアプリ作成」はまぁ、APIトークンを使いようがないので仕方ないですが、
その他のデプロイ系APIが軒並みトークン未対応ですし、
ルックアップフィールドの更新に未対応とか、ちょっとした落とし穴も多いのが辛い。
原則すべての操作をAPIトークンで可能にしてもらえると、開発者的にはとても助かります。
同じくパスワードを使うか、場合によってはルックアップを諦めてAPIからの更新側を優先にしてる時もあります。
OAuth2の実装は別のシーンで効果が出そうな感じなのでもちろん有難いですが、APIトークン周りは改善を期待します。
手前味噌ですが、先月CLI向けのOAuthクライアント作りましたー。
よかったら使ってみてくださいませ。
https://github.com/goqoo-on-kintone/gyuma
kintoneのOAuth設定画面で、リダイレクトエンドポイントに
https://localhost:3000/oauth2callback
と書いて、その状態でローカルでgyumaを実行すると、
サーバー証明書作成・ローカルhttpsサーバー起動まで自動的に行って
ブラウザが開いてkintoneの認証画面が出ます。
認証が成功したあとは、
にアクセスするとトークン情報がJSONで取得できます。
使い方間違えると危険なので、用法・用量を守って正しくお使いくださいw
ありがとうございます、面白そうですね！
どんな時によく使われているのか、参考までにお聞きできれば。
ginueをOAuth認証で使うのが一番メインですね。
https://github.com/goqoo-on-kintone/ginue
デプロイ系はAPIトークンが使えないので、
普通にやろうとするとパスワード毎回入力orローカルに保存しないとダメなんですが、
OAuthを一緒に使うことで「ブラウザでログインできればCLIが動く」
という素敵な状態が実現できるのです。
kintoneのパスワードはどこにでも保存したくないので、
「このブラウザでだけログインできればあとは全部うまくいく」
という便利＆セキュアな環境を作れるわけでございます。
（ginueのOAuth対応は、まだnpmリリースまではできてないんですけどもw）