API Meetup運営チームの@tomigarashです。
API Meetup Tokyo#13を2016/04/08に開催しました。テーマは「企業間連携を加速させるAPI、そしてそこに必要な認可フレームワークOAuth！」で、まとめ情報は下記にあります。
まとめ情報
Togetterまとめ
セッション資料1-スタートアップと大企業のAPI連携 By トレタ増井さん
セッション資料2-API提供におけるOAuthの役割 By NRIセキュア工藤さん
セッション内容自体は公開資料で確認ください。今回両セッションでひとつの共通項があったと感じましたので、そのあたりを纏めます。
4th Party
工藤さんセッションより「OAuthは認可、OpenIDは認証を担う。認証サービスの利用ユーザー視点で考えた場合に、誰かに権限を移譲するようなユースケースにOAuthは対応できない。これをカバーするのが OAuth2.0をベースに策定されたUMA(User Managed Access)であり、4th Partyからのアクセス認可を可能にする。」との事。個人的に4th Partyを前提としたアーキテクチャ設計の話をプロトコルでなくフレームワークで担保するモデルの話には初めて出会った。
そもそもAPIとはサービス提供者が公開し、そのサービスの利用者がAPIを利用して自由にアプリケーションを構築するものであるが、多くの場合そのユーザーが提供するのもまた別のサービスとなる。さらにそのユーザーのサービス自体を他者（他社）に移譲するモデルは多分にあると考えられ、むしろ今後は増えていくと思われる。APIを使ったMashupモデルがより具現化されていけば尚更。
企業連携とAPI
トレタのサービスは、予約関連の共通データーベースをWebサービス運営企業向けにAPI形式で提供。今回のテーマで言えばその各社とは大手企業にあたり、API連携する大手企業側からすればトレタ以外にも複数企業と連携する（したい）のは自然な事業戦略であり、その仕様は横展開を考慮して限りなくオープンスタンダードにすべきというのが増井さんの意見。Webサービスの場合、特に連携先企業がそのユーザーに様々なサービスを提供するモデルが当てはまるので、とても納得のいくストーリー。
ビジネスと開発が近くなるワケ
トレタの場合には予約情報を各社に提供するわけだが、その連携先企業がどういうサービスをエンドユーザーに提供するか、さらにエンドユーザーが今後どういうサービスを連携先企業に求めるか、業界を俯瞰したニーズ把握とそれに基づいたサービスデザインが重要だという示唆があった。セッション途中にも、システム実装前に想定できていなかったユースケースの具体例もあった。これは最近のWebサービスが従来からの共通化を前提に考えられてきたシステムアーキテクチャに当てはまらないものであり、新サービスが既存のシステムモデルから遠ざかっている大きな要因だと考えられる。
認証認可と企業連携、視点は全く違えど捉え方がリンクしていてとても興味深いMeetupとなりました。