デジタルコンストラクションセッション (Authlete for Digital Construction)

この文字起こしは、2022 年 12 月 7 日に開催された Authlete Customer and Partner Meetup 2022 のプレゼンテーションのひとつです。 株式会社 EARTHBRAIN の、技術開発G テクニカルリード 赤澤仁士氏、技術開発G シニアエンジニア イェン ファン バク氏に、建設現場をはじめとする IoT 分野での OAuth の適用と、その中での Authlete の活用をご紹介いただきました。

はじめに

まず建設業界、あるいは建設業界に対するデジタルソリューションについて、馴染みのないかたも多いと思います。そちらについて冒頭で説明します。

次に、我々が取り組んでおります、プラットフォーム開発プロジェクトについて、なぜそれをしているか、またそこでどのように Authlete を利用しているか説明します。

そして、我々が選定するにあたりどのようなことを考えたか、その採用までの経緯を説明いたします。

EARTHBRAIN と SmartConstruction

EARTHBRAIN は、設立されてまだ 1 年半、去年 7 月に設立した会社です。

建設業界のプロセスのデジタル化、いわゆる DX を進め、生産性、安全性、環境適合性を高めていくというビジョン・ミッションを掲げています。

成り立ちですが、建設機械の小松製作所の子会社です。合弁会社となっており、NTT コミュニケーションズ、ソニーセミコンダクタソリューションズ、そして野村総合研究所から出資を受けています。

建設業界を取り巻く課題

2025 年に技能労働者の 4 割が離職

我々はなぜ建設業界の DX を進めているのか。 左側の図にある通り、建設業界はどんどん人が減っています。とくに、技能を持ち現場で作業をしてくださる人が減っています。とはいえ建設の需要は減っておらず、やや微増ぐらいの状況です。その結果需給ギャップが発生してきますが、人を増やすのは難しいです。そこでデジタル技術を使って生産性を上げ、そのギャップを埋めていくのが、我々のやりたいことです。

建設会社の 90% 以上が中小事業者

また右の図表に示していますが、建設業界の 90% 以上が中小事業者です。デジタル化に取り組み辛いという状況にあります。そこに対してソリューションを提案し、業界全体の生産性を高めていきたいと考えています。

生産性・安全性・デジタル活用の向上

建設業界は他業種と比べて、生産性や安全性、またデジタル活用など、向上できる余地がある状態です。我々のソリューションが、寄与できればと考えています。

建設プロセス全体のデジタル化へ

スマートコンストラクション

センサーキットを後付けし ICT 施工を実現

提供している具体的なサービスをご紹介します。

まずこちらの油圧ショベル。道を歩いているとよく見かけると思います。もともと、センサーがついた「ICT 建機」がありましたが、高価であったり、すでに油圧ショベルを持っていたり、という状況がありました。そこで、すでにお持ちの油圧ショベルに後付けできるセンサーキットを提供しています。

建機やダンプカーの位置情報をリアルタイムに把握

また、建機やダンプカーの位置情報を知りたいというニーズがあります。これに対し、専用デバイスやスマホアプリを作り、それを載せておくと、その場所がリアルタイムにわかる、というソリューションを出しています。

現場を 3D で隅々まで「見える化」

こちらはさきほど申し上げた、3D で現場を表現するソリューションです。ブラウザ上で、現場を表現できます。このように現場を 3D で表現すると、たとえば、こんなふうに斜面を削ったら土の量はどれくらいになるだろう、というのが計算できます。また、面積をブラウザ上で計測したり、アノテーション（注釈）をつけたりできます。

プラットフォーム開発

ここからは我々が現在取り組んでいるプラットフォーム開発についてご説明します。

プラットフォームの役割

さきほど申し上げた 3 つの例や、開発中のものも含め、この図にある四角の一つひとつが、我々のソリューションです。

さきほど、横の連携が大事であると申し上げました。デバイス、ハードウェア、スマホアプリ、そして Web アプリなど、いろいろな提供形態があります。それをどうやって連携させるか。

我々はこの灰色の部分、プラットフォームのレイヤーを構築し、3 年ほど運用しています。役割としては、認証・認可、データの受け渡し、そしてユーザー、企業、建設業界特有の「現場」という概念、またライセンスの管理などを担っています。

今回 Authlete を採用させていただいたのは、このプラットフォーム開発プロジェクトです。

5 つの要件

そのようなことで、今回のプラットフォーム開発プロジェクトを進めています。ここからはエンジニアの Bach にバトンタッチして説明を続けます。

IDaaS と BaaS (Authlete)

約 200 種類の API を提供

こちらが我々のプラットフォームです。このプラットフォームの内製化プロジェクトをやっています。

いろいろな建機がプラットフォームへ、API 経由でデータを送信します。プラットフォーム内ではデータの保存・処理を行います。また、API 経由でアプリケーションと連携します。プラットフォームの API は OAuth 2.0 によって保護されています。またログイン処理が必要なアプリケーション向けに OpenID Connect も提供しています。API の本数はかなり多く、約 200 種類あります。

外部 OAuth /OIDC サービスの選択肢

OpenID Connect や OAuth 2.0 については、詳しい人間が内部におらず、外部のサービスを使う予定でした。

外部サービスには 2 つの選択肢がありました。IDaaS (Identity as a Service) と BaaS (Backend as a Service) です。IDaaS は「あるソリューション」、BaaS は Authlete を指しています。

ある IDaaS を当初は検討した

ただし一点、柔軟性に関しては、BaaS のほうにメリットがありました。IDaaS はそのまま使える機能をいろいろ提供していますが、我々のプラットフォームの必須要素と異なる部分があるため、IDaaS の柔軟性は △（三角）としました。BaaS ではそもそもそのような機能が提供されていないため、実装する必要はありますが、柔軟性は高いと言えます。

IDaaS 検討から見えてきた 5 つの課題

IDaaS の検討にあたり、PoC を実施しました。すると、IDaaS の機能を活かしきれないことが徐々にわかってきました。課題が 5 つありました。

1. エンドポイント仕様の不一致

IDaaS が提供するエンドポイントが現行プラットフォームのインターフェースと一致せず、OAuth の規格も満たしていません。IDaaS を使うためには、それらのエンドポイントをラップする必要があります。

2. パスワードのハッシュ方法の制限

パスワードを IDaaS 、もしくはカスタムのデータベースに保存するとした場合、IDaaS の対応可能なハッシュ方法が限られているため、現行プラットフォームのハッシュ方法に対応できません。こちらの部分も独自に実装する必要があります。

3. サインアップ処理の機能不足

IDaaS にはサインアップ機能がありますが、その他のいろいろな機能、たとえば ユーザーのプロフィール画像や、現行プラットフォームが備えていたメール確認機能などはサポートしていないため、独自実装が必要です。

4. アクセストークンの表現力不足

IDaaS では、アクセストークンに含めるクレームの要件を完全に満たせません。

5. アクセストークン失効機能の不備

アクセストークンを選択的に失効させる機能がありません。

IDaaS は BaaS (Authlete) より大幅にコスト増

こちらは IDaaS と BaaS の比較です。

IDaaS の機能はほとんど使えず、API をラップしたり、独自実装したり、といった作業が必要となります。

後半の2つの課題についてです。

IDaaS では、アクセストークンに含めるクレームに関し、要件を満たせません。任意クレームの追加はできますが、クレームのキーは URL 形式でなくてはなりません。そのため、既存のアプリケーションを修正する必要があります。それは我々としては望ましくありません。一方 BaaS では、任意クレームの追加が可能であり、かつ、キーは URL 形式である必要はありません。ただし利用可能なクレームの値は、当初は文字列型のみでした。そこで Authlete さんに相談したところ、配列型も Authlete 2.3からサポートされるようになりました。

最後の失効機能について、もともと IDaaS にはそのような機能が存在しません。一方 BaaS では提供されています。

Authlete の採用

Authlete 社と機能追加を議論

ということで、BaaS を優先的に検討することにしたのですが、しかし当初は Authlete もそのまま使えるかたちではありませんでした。そこで Authlete さんと議論し、いろいろな機能を追加してもらいました。具体的には次の4つです。

JWT 認可グラント

ひとつ目が JWT 認可グラントです。これは現行プラットフォームにある認可フローのひとつです。Authlete は当初このグラントをサポートしておらず、もしそのまま非対応となった場合には、認可サーバーの実装は困難になることが想定されました。

しかし Authlete さんに相談したところ、5 日間という非常に迅速な期間で実装していただけました。我々にとって大変役に立ちました。

JWT アクセストークンの配列型対応

次の機能は、先にお話ししたアクセストークンです。我々のプラットフォームでは、アクセストークンは JWT 形式であり、ペイロードに配列型の値を含んでいました。しかし Authlete バージョン 2.2 では、配列型の追加はできませんでした。つまり、このスライドの赤字で書いた部分の追加ができないことを意味していました。

しかし、Authlete バージョン 2.3 から jwtAtClaims パラメーターが追加され、こちらを経由して配列型を追加できるようになりました。

Token Exchange

次はトークン交換の機能です。こちらは土木業界で必要とされる規格です。

具体的には、サブジェクトトークンとアクタートークンを用いて、新しい種類のトークンを発行するものです。詳しい内容は Authlete さんの記事を参考にしてください。

クライアント単位での PKCE 設定

最後は PKCE です。我々のプラットフォームには、PKCE の利用が必須化されていない（任意とされている）クライアントも存在します。

そのため、PKCE の必須化をクライアント単位で設定できることが非常に重要です。Authlete さんに相談し、そのように設定できるようにしてもらいました。

Authlete の Go ライブラリを利用

開発の流れを少しお話しします。

当初、我々には OAuth 2.0 と OpenID Connect の知識がほとんどありませんでした。しかし Authlete さんがいろいろな言語の実装のリポジトリを提供しており、我々はその中から Go 系のライブラリを参考にして認可サーバーを実装できました。

Go 系のリポジトリには 3 つあります。ひとつは authlete-go です。こちらには DTO や const の定義があります。もうひとつは authlete-go-gin です。認可サーバーをかんたんに実装するためのコンポーネントを提供しています。最後に gin-oauth-server が、認可サーバー実装の例です。

PoC 的に実装してみたところ、すぐに Go で必要な API を動かせました。なお本番環境では、authlete-go のみを実装に用いています。

以上で発表を終わります。ご清聴ありがとうございました。