社内向けのWebサービスでの社内システム連携のやり方

日々

仕事で社内システムとWebAPI連携しないといけないんだけども、そのやり方について正しいかわからなくなったので自分の考えをまとめておく。

例：社内システムS

例えばこんな情報を扱う社内システムが存在したとする。

  • システムA: 社員の情報
  • システムB: 社員に支給したPCや携帯端末の情報
  • システムC: 社員が扱える権限の情報(セキュリティエリアの入室権限などの管理)

これらを使って社員の情報がスパッと見れるイカした社内システム(以下、S)を作るという話になった。
システムSは認証が必須であり、ログインしている社員の認証情報を使えば各システムとの連携もできるだろう、というもの。

各システムとの連携方法

どれもWeb APIを提供している。
なので基本的にAJAXを利用してブラウザ→システム(A,B,C)と直接連携する。

また、連携方法の違いがある。

  • A: システムごとに払い出された認証情報を一緒に送る。(サポートするメソッドはGETのみ。)
  • B: システムごとに払い出された認証情報を使い、認証キーを取得。認証キーと一緒に送る。
  • C: システムごとに払い出された暗号鍵を使い、独自の方式で暗号化された情報と一緒に送る。

ここに出てくる認証情報や暗号鍵は、当然システムS用に特別に払い出してもらったもの。

問題点

  1. 認証情報丸見え
  2. システムごとにAPIの投げ方が違う

1については、社員は認証情報を見れる状態にあるということ。システムSになりすましてシステムA,B,Cを利用することだってできる。社内システムなので別にいいんだろうけども、社長が持ってる情報に普通にアクセスできてしまう。

2について、システムごとにAPIの投げ方が違うと、APIを投げるためのコードを割と書かないといけない。OAuthなどに準じているわけでもないので、頑張ってコードを書かないといけない。

他の理由として、API設計が残念などもあるが、直すのは無理だろうからここでは言及しない。

対処案

APIを代理で叩くAPIサーバを作る
  • メリット
    • 認証はシステムSの認証で済ませることができる
    • 各システム(A,B,C)の認証情報をクライアントから隠ぺいできる。
    • 各システム(A,B,C)のAPIの仕様が変わっても、影響がAPIサーバ内で済む。
    • リクエストの仕方を統一できる。
  • デメリット
    • APIの設計・開発・メンテナンスのコストが発生する

デメリットの行が1行しかないけどこれは見た目以上に重い。

個人的な考えとして、システム毎に認証情報を払い出している場合、認証情報を払い出されたシステムを通さずに直接触らせるのはNGだと思う。なので、システムSの一部にAPIサーバを作ってそこを通して連携しましょう、という考え。

これしか思いつかない。でもこれが一番ベストなんではないか？と考えている。他にうまいやり方があるのかな？

おしまい

このあたりの話ってあまり聞かない・・・当たり前すぎて話すことでもないのかも。Twitterと連携するときにシークレットキーを開示するわけがないし。

けど、当たり前のようにユーザにシステムの認証情報を晒している状況を見てると、自分の考えが正しいのか不安になってきてしまう。
ここ最近はいつもこんな感じで自分の判断に自信が持てない。でも誰かに聞いても納得がいく回答が得られない。