本記事は2016-09-28（水）に開催された【開発者向け】 EC-CUBE API プラグイン勉強会の参加レポートです。株式会社ロックオン 大阪本社で開催されました。スピーカーはEC-CUBE公式エバンジェリストの大河内 健太郎さんです。
まとめ
API開発の背景
- 今時APIなんて当たり前だよね
- IoTとかSSOとかしたいよね
EC-CUBEの情報を扱うにはリスクもある
- 個人情報、決済に関わる情報も持っている
- セキュリティ対策の不備は重過失と認定される危険性
- 安全な認証が不可欠
- 一般的なのはOAuth2.0。TwitterとかFacebookでも使われている
- みんながよくやってるのはクライアント側。サーバー側の実装は大変
EC-CUBEのAPIの要件とは？
- 全機能API対応？？ざっくりな要件。マジかよ…と思った
OpenID Connectとは？
- OAuth2.0の拡張版
- アプリケーション間の相互妥当性検証が可能（ここ重要）
- OpenID Authorization 2.0 とは別物なので注意
- OpenID Connect 以外に安全な認証の選択肢がなかった
- PHPのオープンソースCMSでちゃんとやっているのは少ない。そのため、当初全部自分で書くことを覚悟したが…oauth2-server-phpを発見。OpenID Connectもサポートしていた
- ライブラリをベースに、RFCに準拠するよう実装していく地味なお仕事
EC-CUBEでは OpenID Connect Core の主要部分をサポート！
- OPTIONAL扱いのものや、EC-CUBEでは使わないと思われるHybrid flowなどは未サポート
- Customer と Member に認証を提供している
- APIクライアントは、各ユーザーと1対1の関係
ドキュメントに従ったデモ
https://ec-cube.github.io/api_authorization.html
- CSRF防止のためのstateパラメータは必須
- OAuth2.0では推奨パラメータのため、一般的なOAuthクライアントライブラリではサポートしていないものも多いので注意
- Google Identity Provider を参考に追加実装したものもある
- tokeninfoエンドポイント=id_token の詳細情報をJSONで返す
- Authorization Code Flow にて、 redirect_uri に urn:ietf:wg:oauth:2.0:oob を指定することで、 ブラウザの画面に Authorization code を表示できる。ネイティブアプリなどに利用可能
SSOの用途には、まだ改良が必要
CRUD API について
- RESTfulなAPIを実装
- del_flgのあるテーブルのみDELETEに対応
- 整合性チェックはDBに依存
- JSONとEntityのMapperを独自開発
- DB定義にAPIの仕様が依存している
今後の展望
- OpenID Connect Provider Certification を取得したい
- サービス志向の高レベルAPIを作りたい（さすがにテーブルと対応したAPIだけでは使いづらい）
- ２系に移植できれば夢が広がる（時間と体力とモチベーションに余裕があれば）
感想
concrete5 にもREST APIを実装しようと考えているので、OpenID Connect においてPHP界での取り組みが進んでいないことや、EntityとJSONのマッピングの考え方など、色々参考になりました。EC-CUBE 案件で実際にAPIの利用を検討していることもあり、現状のエンドポイントでどんな処理が可能なのかから、調べていきたいと思います。有意義な勉強会を開催されているEC-CUBE関西ユーザグループの皆さんに感謝します。
