Salesforce が OAuth をサポート

salesforce oauth

情報キャッチ遅れた。今日やっと知った。正直彼らがWebサービス周りでアグレッシブなアーキテクチャ変更するとは思わなかったので、ちょっと意外だった。

Remote Access Applications with OAuth | Winter '10 | Releases

上記にはたいしたことは書いてないが、下記のリリースノートに若干記述がある。それ以外の（開発者にとって）有用な技術情報はまだ出てない（ような気がする）。

Salesforce.com Winter '10 Release Notes

ちなみにWinter'10とはSalesforceの最新バージョンで、既に有効になっている環境もある（Salesforceの場合サインアップしたときの条件によって別々のインスタンスがルールに従って割り与えられるため、アップグレードのタイミングもまちまち）が、この機能が使えるようになるのは若干ずれて 2009年10月12日以降らしい。なのでこの記事を書いている現時点ではもう少し待つ必要がある。

      • -

以下、想像に基づくため、実際の資料が出てきてから補足修正する予定で書く。

インパクト

まず、Google Apps と異なり、もともとの出自が企業向けのサービスであった会社のサービスがOAuthに対応したこと。もちろんJIRAなどの例もあるが、知名度を考えると、これを皮切りに今後OAuthがエンタープライズ系プロダクトの世界にも広く採用される可能性は十分にある。

今までのWebサービスAPIはどうなるか？

SalesforceにはもともとSOAPベースのAPIがあるが、このAPIの認証はSOAPヘッダの中にセキュリティトークンとしてのSession IDを埋め込んでメッセージを送るという独自の仕様で実現されている。OAuthではHTTPボディとしてのSOAPエンベロープ内にAccess Tokenを設定することは考えられてないので、これはそのままではまったくOAuthと互換性がない。なのでSalesforce APIサービス側でこれに対処する必要がある。

やり方として、

  • 新たにOAuthを受け付けるRESTベースのAPIを導入する

がまず考えつくが、SalesforceのWebサービスの稼働実績を考えると今からそちらに踏み切るのには開発者にもインフラにも双方にコストがかかりすぎる。なのでこれはあり得ないと思う。

おそらく

  • OAuthのAccess Tokenを従来のAPI認証に利用できるSession IDに変換する新たなAPIエンドポイントを設ける

のようなやり方になるのではないか。これであれば今までのAPIクライアントライブラリはほぼ使い回しができるし、インフラ側も特に負荷があがるわけではない。

Salesforceに対してOAuthコンシューマの登録はどのようになるのか

これは若干リリースノートに記載がある。ただ、Salesforceのアプリケーションパッケージングの仕組みを知っていないとちょっとわかりにくい。特に管理パッケージ(managed package)という記載が出てくるが、これはSalesforce全インスタンス上で一意の名前空間をパッケージにつけるための仕組みになる。このパッケージにひもづけてOAuthコンシューマを登録することにより、Salesforce上で一意になるコンシューマを登録することができる。

ほかのOAuthサービスプロバイダと違う点は、Salesforceを契約した企業のシステム管理者が上記のパッケージをインストールしないと、その企業（組織）内のユーザはOAuth認証を利用できないという点。ちゃんと管理者が承認したものだけが利用できるのである意味ではセキュアだが、ある意味ではせっかくのOAuthなのにもかかわらずユーザセントリックではない。

OAuthコンシューマにはならないのか？

Salesforceを営業支援／CRMサービスとしてのみ認識していると気づきにくいが、SalesforceがOAuth対応、というときには考えられるパターンとして２種類あって、それはSalesforceがOAuthサービスプロバイダになるかあるいはコンシューマになるか、ということ。SalesforceにはApexという独自のプログラミング言語／実行環境があり、Salesforce上にホスティングしたプログラムから外部Webサービスにリクエストを投げられたりするので、Java/Perl/Ruby/Python/PHPなどと同じようにOAuthのコンシューマライブラリが提供される可能性はあり得る。僕自身、最初はサービスプロバイダではなくコンシューマでの対応の方だろうかと考えていた。
これについては、特に問題があるわけではないように思えるが、どうなのか。今回は同時ではないかもしれないが（Google Apps統合を中心にして）需要も多そうなのでいずれサポートされてもおかしくない。Salesforceの場合は複数の組織／アプリケーションが同一のURL上で共存できるマルチテナントであるためにちょっとめんどくさいことが多そうな気がするけれども。

OAuth対応はOpenSocial化への布石？

OpenSocial発足時にsalesforce.comも名を連ねていたことを覚えている人はそう思うかもしれない。もちろんそうであってくれるといいが、個人的には、何となくそれに関しては悲観的である。というのも、OpenSocialの想定しているSocial Graphと現在のSalesforceの想定する人間関係のモデルでは違いが大きすぎるし、何よりもまず、Social Graphとして開放することに対するビジネス要求がそれほどない。別の言い方をすると、データは既存のAPIで十分に開放されている。
OAuth対応についてのメインの動機は、リリースノートの例にもある通り iGoogle ガジェットからセキュアに（ユーザ／パスワードを保存させることなく）Salesforce内のデータにアクセスできるようにするためである気がしている。そしてこれはおそらくSalesforceのGoogleへの（しばしば一方的な）愛による。