機能が充実してかゆいところに手が届くようになってくると、いろいろかんたんにできちゃうことが増えて来るので、気を引き締めて開発しなきゃならないですね、kintone。
2019年12月 の複数APIトークン対応に引き続き、APIトークン認証の対応のアップデートがありました。
開発者側では比較的待望となっていたアプリ管理系も対応し、2020年4月のアップデートを以て
これにより、システム管理権限が必要な API を除くすべてのアプリ設定 API が、API トークン認証で利用可能となりました。
やったぜ！って思っている人が居るとか居ないとかは置いておいて、今回はAPIトークン認証についておさらいしてみます。
手前勝手ながら2020年度のジョイゾーは新入社員も入社しましたので、kintone開発初心者・お勉強中の方向けの記事にしてみますね。
プログラムちゃんもkintoneにログインしないとならないよね
さて、登場人物はkintone上で動く「プログラムちゃん」、プログラムちゃんを「使う人」、そして「使わせる人」です。
「使わせる人」は「管理者（開発者）」、一般のkintoneユーザーに「プログラムを使わせる」側の人。
kintone環境、kintoneに置かれたデータ・情報を守る立場、と置き換えても良いですね。
「使う人」はこの画面を使ってkintoneにログインしますよね。
ログイン名とパスワードが必要です。
「プログラムちゃん」がkintoneのアプリやレコードにアクセスするためにも、同じようにログイン、「認証」が必要です。
最初からkintoneの中に居るプログラムちゃんは、基本的に使う人の鍵を借ります。
使う人がログインしたとき以降、ブラウザはこの人の鍵を一定期間保持します。
この鍵を使ってプログラムちゃんがkintoneのデータにアクセスするのが「セッション認証」です。
このとき、プログラムちゃんに事前に鍵を預けておく必要がありません。
プログラムちゃんはkintoneの外に居るときもあります。
例えば他のシステムと連携するために、AWSなどの外部サービス上にプログラムちゃんに居てもらい、定期的にあっちからこっちへデータを持ってきて、、などのお仕事をしてもらう場合です。
このときはプログラムちゃんに鍵を預ける必要があります。
鍵がなければ外からkintoneには入れませんね。
このとき、預ける鍵には２種類あります。
１つは
・「使う人」の中から代表者を選んでこの人の鍵（ログイン名とパスワード）を預ける。
これが「パスワード認証」です。
もう１つが、アプリ毎につくることができる鍵、
・APIトークン
です。これをつかった認証を「APIトークン認証」といいます。
APIトークンの出番は？
さっきはkintoneの中と外、ということで「お家（うち）」の図でしたが、kintoneの中にはアプリという「お部屋」があって、それぞれに権限の制御があります。鍵をかけてあれば、鍵が無い人は入れません。
「APIトークン」は、アプリ毎に発行されるアクセスキーですので、どちらかというと「お部屋」の鍵です。
パスワード認証だと、「プログラムちゃん専用アカウント」を用意しない限り、「誰かさん」の鍵をずっと貸しっぱなしにしなければなりません。
しかも、多くの「誰かさん」は複数のお部屋に入れたり、それぞれの権限も変動することがありますよね。
プログラムちゃんに意図しない権限を与えてしまうことにもなり兼ねないですし、セキュリティ、メンテナンス面で良くないケースもあるでしょう。
この点、APIトークンは便利です。「プログラムちゃん専用”鍵”」を作ることができます。
５種類の権限の組み合わせで必要最低限の権限を与え、かつ複数用意することもできる（アプリ毎に20個まで）ので、特定のプログラムちゃんのお仕事に合わせた独自の鍵を作ってあげることができるのです。
2019年12月 のアップデートで複数APIトークンに対応したからできるようになったことは良い例ですが、これまで、APIトークン認証では「ルックアップ」や「関連レコード」など、「他のアプリと紐付けてデータを使っているフィールド」についてはアクセスができませんでした。
案件の部屋の鍵では顧客、担当者マスタの部屋には入れないからです。
ここでプログラムちゃんに、必要な部屋の鍵を一度に渡せるキーホルダー機能みたいのが付いたわけですね。
鍵があるのでプログラムちゃんは、案件部屋で他の部屋のデータを使っているフィールドを使えるようになりました。
じゃあどんどんAPIトークンで行っちゃえばいいよね！
そうでもありません。
APIトークンは便利ですが、プログラムちゃんを使う人に、本来持っていない権限を与えかねません。
ユーザーに閲覧権限の無いアプリからレコードを取得させることもできてしまいます。
APIトークン認証を通して実行したプログラムちゃんのお仕事は、Administoratorが実行した、という履歴が残ります。
ここから想像できるとおり、「限定的ではあるけれどAdministoratorの権限」を、プログラムちゃんを使う人達に預けることと同等です。
ただしAdministoratorとイコールではないので
例えば、フィールドの権限を制御しているアプリでも（Administoratorにフィールドの閲覧権限を外したとしても）、APIトークン認証でレコードを取得するとこのフィールドは見えてしまいます。
筆者はすごーく、気をつけて使わなければならない認証方式だと思って使うようにしています。
外部のプログラムちゃんが何人も居る場合、権限区分が同一であれば同じAPIトークンを使い回すこともありますよね。
でも、何らかの事態が持ち上がり、プログラムちゃんAの処理の権限を変更しなければならない。あるいは、処理を停止させAPIトークンは削除しないとならない。といった場合に、BちゃんもCちゃんも影響を受けてしまうので、基本的にはプログラムちゃんごとにAPIトークンを作ってあげるのが良いかもしれないですね。
いずれにしても
パスワード認証でも、APIトークン認証でも同じことですが、認証情報は見えちゃだめです。
特にブラウザ側にJavaScriptでプログラムちゃんを実装するときには、プラグイン側で隠して置いておくのは必須です。
上の画像みたいに書いちゃうなんてもってのほか。
画面上に見えてなくてもコードに書いた時点で植木鉢の下に鍵を隠してるみたいなものです。
外部サービスにおいても環境変数に置くなどして、コード内に認証情報を書くのはやめましょう。
