自己紹介

はじめまして！株式会社SHIFT カスタマーサクセスグループ Salesforceチームの倉田と申します。

入社後はDAAE（ダーエ）部という部署にいたのですが、どうしてもSalesforceでの開発が忘れられず、カスタマーサクセスグループに異動しました。 こうした柔軟な部署異動ができるところもSHIFTの良さかなと思っています。

私はどちらかと言うと技術的なことが好きですので、NoteではSalesforceのインプリ案件で役に立ちそうなTIPSを書いていこうと考えています。

どうぞよろしくお願いいたします！

この記事の想定読者

①OAuth2.0 JWT ベアラーフローについて具体的なイメージが湧かないSalesforceの開発者
②SalesforceでAPI開発をしようとしている方
③SalesforceのAPIを外部システムからコールしようとしている方

この記事のゴール

★OAuth2.0 JWT ベアラーフローについて、この記事の読者が具体的なイメージを持つこと

はじめに

SalesforceのAPIを外部システムからコールする際に、認証（そして認可）周りの検討は必ず必要となります。 この認証に関しては、書籍やネット上の情報はあるものの、イマイチとっつきにくいのも事実かなと思います。同僚からも「イメージが湧かないから試してみたいけど、ネット上の情報通りにやっても何だかうまくいかないのよね・・・」というような話を聞きました。

そこで、Salesforceで実装したAPIを、OAuth2.0 JWT ベアラーフロー経由でコールするまでの具体的な流れを、備忘の意味も含めて記事にします。外部アプリから呼び出す流れにしてしまうと、コーディングの解説も必要となってしまいますので、今回はPostmanを使ってAPIをコールします。

今回の記事はシリーズもので、この記事の後に ②準備編 と ③実行編 が続きますので、併せてご覧いただければ幸いです。

なぜOAuth2.0 JWT ベアラーフローなのか

読者様はDataloaderを使ったことはありますでしょうか？ ここは使ったことがある前提で書かせていただきます。

まず思い出していただきたいのですが、Dataloaderを使う際には認証が必要となります。「OAuth」と「Password Authentication」の2択です。OAuthで認証しようとするとパスワード入力画面が開きます。

外部システムからAPIをコールする際にも、Dataloaderと同様に認証が必要です。 ですがDataloaderのように、API実行時に毎回パスワード入力画面が開くどうなるでしょうか。恐らく困ったことになります。ユーザーからはクレームが入ることでしょう。

そこで、パスワード入力画面が不要な認証方法を選択する必要が出てきます。

選択肢として「OAuth 2.0 ユーザー名パスワードフロー」もありますが、この方法ではユーザーIDとパスワードを保持することになりますので、セキュリティ的に問題があるかもしれません。

特別なシナリオの OAuth 2.0 ユーザー名パスワードフロー

もう一つの選択肢として、この記事で取り上げる「OAuth2.0 JWT ベアラーフロー」があります。 この方法では、パスワードの代わりに自己署名証明書や秘密鍵を利用します。

サーバー間インテグレーション用の OAuth 2.0 JWT ベアラーフロー

この「OAuth2.0 JWT ベアラーフロー」にはハマりポイントがいくつかあり、初めて実装する場合は意味不明なエラーが発生して途方に暮れることがあるでしょう。

でも大丈夫です。
この後１つずつ作業をしていって、最終的にはAPIをコールするところまでの具体的な手順を記載します。
長い記事となるかもしれませんが、一緒について来てください！

※　②準備編に続きます。

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/