認証/認可処理の実現方法の検討と運用してみての感触

こんにちは！アルダグラムでエンジニアをしているヤスです。

始めに

KANNA では世界中のノンデスクワーカーに使われる SaaS を意識してプロダクト開発を行っております。

https://lp.kanna4u.com/

しかし、toB 向けのサービスであることから、以下のようなご要望も一定数存在します。

• ビジネス要件上どうしても個社ごとに最適化を行いたい
• 他 SaaS や自社システムと KANNA を連携したい

そのような場合、契約した会社自ら、プロダクトの拡張を行っていただくために、KANNA のリソースにアクセスできる 外部連携用のAPI を開発いたしました！

https://lp.kanna4u.com/feature/

今回は開発にあたって、

• 基盤となる認証形式をどのような形で議論し決めていったのか
• 採用した認証方式の簡単な説明

をお話しできればと思っています。

認証形式に関する議論

API を公開するにあたって、主な認証処理としては以下が挙げられます。

• API キーによる認証
• OAuth 認証
• Basic認証

一般的なシステムで API を連携する場合、 API キーを発行することにより、テナント内のリソースにアクセスし、システム間連携を実現する方法が多いかと思います。

この方法で連携を行うためには、ユーザーのモデルと API を用いてアクセスするリソースが疎結合である必要があります。

KANNA のリソースはユーザーと密接な状態にあるので、API キーによる連携は実現することが難しい状態にありました。

また、ビジネス上の要件として、個社ごとに最適化を行う際にはユーザー毎に閲覧できるリソースの絞り込みや制限を設ける必要がありました。

このような状態であったため、OAuth による認証を採用しました。

OAuth による認証を採用したことで、KANNA 上で利用しているユーザーごとの権限モデルを 外部連携用のAPI にも適応することができるので、個社ごとに開発する際により柔軟な開発が可能になっています。

KANNA 上の権限モデルを適応できるので、KANNA 全体の変更に対応できるため、API 開発にあたり特別な設計などが必要ない状態にすることができました。

OAuth 2.0 に関して

OAuth 2.0 の仕様に関して説明した記事に関しては、多くの記事が存在します。

標準的な仕様としては、RFC 6749 に準拠する必要があります。

https://tex2e.github.io/rfc-translater/html/rfc6749.html

簡単にまとめると、以下の要件を満たす必要があります。

1. サービス提供者は利用者に クライアントID と シークレットキー を提供します
2. 利用者は 1 を用いて認可サーバーにアクセスします
3. 認可サーバーは利用者に指定されたエンドポイントに対して、認可コードを発行します
4. 利用者は認可コードを用いて、アクセストークン・リフレッシュトークンを取得します
5. 利用者はアクセストークンを用いて、リソースにアクセスします

KANNA では、3 の認可処理に関しては、KANNA の Web システムにログインしていることで認可を行うようにしています。

シーケンスにするとこうなります。

一度認可した後は、リフレッシュトークンを用いることで、継続的にアクセストークンを更新し続けることができます。

この仕組みを用いることで、再認可を行うことなくリソースにアクセスすることができます。

m2m の連携を行う際は、システム連携用のユーザーを発行してもらうことで対応しています。

最後に

OAuth 2.0 の方式を採用しましたが、現在のところ問題なく使われているようです。

課題感としては、

• 認証情報の発行に弊社の CS が関わっていること
• システム連携を行う際に技術サポートが必要なケースがあること

が挙げられます。

顧客様自身で認証情報を発行できる仕組みづくりや、より簡単にシステム連携を行うことができるようなドキュメントの作成などが必要だと感じております。

データ連携を利用することで、顧客の業務の効率化が図れるケースも増えてきました。

より活用されることを目指して、今後も様々なサービスと連携できるための取り組みを続けていきたいと考えています。

もっとアルダグラムエンジニア組織を知りたい人、ぜひ下記の情報をチェックしてみてください！