eIDAS 2.0でサポート必須のSD-JWT VCフォーマットとmdoc/mDLフォーマットのVerifiable Credentialを同時に発行してみた (たぶん世界初)OpenIDvcMdlmdocSD-JWT はじめに デジタルアイデンティティ業界は Verifiable Credential (検証可能な資格証明) の話題で持ちきりです。特にヨーロッパでは、Verifiable Credential を管理するための EU Digital Identity Wallet (EUDIW) の整備が eIDAS 2.0 という枠組み (法規制と技術仕様のセット) により要求されるため、技術仕様策定と実装が急ピッチで進んでいます。 そんな中、先日 (2024 年 1 月 19 日) 開催された『OpenID Summit Tokyo 2024』では、ドイツ政府機関 SPRIND から
株式会社みんなの銀行（取締役頭取 永吉 健一、以下「みんなの銀行」）は、国内の銀行として初めて(*1)、世界トップレベルのセキュリティ規格『FAPI』に準拠したAPI （*2）連携システムを開発しました。まずは、2022年中に参照系APIの外部連携を開始する予定です。 APIのシステム開発は株式会社ふくおかフィナンシャルグループ（取締役社長 五島 久）のシステム子会社であるゼロバンク・デザインファクトリー株式会社（取締役社長 永吉 健一、以下「ZDF」)が行い（*3）、「FAPI 1.0 Advanced」に準拠するものとして、Open ID Foundation による認定を取得いたしました。 *1：https://openid.net/certification/#FAPI_OP 参照 *2：Application Programming Interface の略。銀行と外部の事業者と
はじめに こんにちは！yamakazu (@yamarkz) です。 近所の行きつけスーパーがサミットストアになったのですが、品揃えがとても良く、お店の雰囲気も明るくて、仕事終わりの買い物が最近の楽しみになってます 🥳 🛒🥗 さて今回は、開発方面のナレッジとして外部API連携の話を紹介します。非常にニッチな領域の話題ですが、わかる人にはわかるような内容です。 興味のある方はぜひ最後まで読んでみてください。 動機 新しく外部API連携の開発に着手するメンバーの助けになりたい、より良い外部API連携を実現したいという思いから、これまで開発を経験してきた中で理解した勘所を紹介します。 元々は社内向けに書き溜めておいたナレッジメモの内容ですが、特別社内に留めておく必要性もないので、せっかくならブログにしてしまおうと思い、ここで筆を取りました。 これは社内の同僚に向けた内容でありながら、似た境
どういうもの？ このように関数を使ってデータを取り込めます。 背景 元々は「インターネット上のWebAPIのデータをExcelに取り込みたい」と思ったのがきっかけです。 VBAマクロを使えば簡単ではありますが、マクロは使いたくないという方も多いのではないでしょうか。かくいう私も勤務先が属人化を防ぐためにマクロの使用を推奨していません。 そこで、関数を使用する方法を選択しました。 ExcelにはWEBSERVICE 関数という指定したURLの応答データを取り込む関数があります。 しかし、この関数は大変便利な関数ですが、ExcelはHTMLやJSONのパーサーを用意していません。結局取り込んだHTMLやJSONの処理にはVBAマクロが必要になります。 また、欲しいWebAPIが存在しない問題もありました。 そこで、Excelでデータを編集するのではなく、元々のWebAPIをExcel用に作れば
※この投稿は米国時間 2022 年 7 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 地域、業界を問わずどの組織も、サービスとデータをより簡単かつ標準化された方法で提供し、デジタル エクスペリエンスを改善するために、API の開発を進めています。デジタル エクスペリエンスへのシフトが顕著になるにつれ、API の使用量とトラフィック量も増加しています。その一方で悪意のある API 攻撃も増加しているため、API セキュリティはビジネスリスクにおける重要なトピックとなっています。 増大する API セキュリティのニーズに対処しやすくするために、Google Cloud は本日、Advanced API Security のプレビュー版を発表します。Advanced API Security は、Google の API 管理プラットフォームである Apigee
LINE株式会社の開発拠点の一つである「京都開発室」が、オンラインのエンジニア採用説明会を開催。銀行事業のサーバーサイド開発について、Robert Mitchell氏、野田誠人氏が話をしました。 LINEの銀行サービスとは Robert Mitchell氏（以下、Mitchell）：サーバーサイドチームのMitchell Robertと申します。本日、野田さんと一緒に、LINEの銀行サービスの開発について発表したいと思います。よろしくお願いします。 今日の内容ですが、以下の通りになります。まずはLINEの銀行サービスとはなにかついて、軽く説明したいと思います。その後、システムアーキテクチャと開発フローについて話したいと思います。最後は、認証と認可で、これは私たちが担当している部分です。これに関連するスペックや、セキュリティの仕組み、フローについて話したいと思います。 じゃあ、LINEの銀行
※この投稿は米国時間 2021 年 3 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。 情報セキュリティに関するトピックは、毎日のように大きなニュースになっています。大小のスキームで使用される悪意ある bot や、有名な大企業とその顧客を巻き込み、最終的に多数の政府機関、民間組織、人に影響を与える全面的な「ソフトウェア サプライ チェーン攻撃」など、さまざまなセキュリティ リスクについて、おそらく耳にされたことがあるはずです。 企業がオンライン チャネルで顧客にサービスを提供したり、場所を問わず世界中のリモート ワーカーと業務を行ったりする目的でデジタル プログラムを拡張するのに伴い、このようなセキュリティ攻撃がより一般的になると予想されています。アプリケーション プログラミング インターフェース（API）は、さまざまなアプリケーションやサービスの原動力と
Tokyo MuleSoft Meetup #5 (online)Nov 19, 2020, 9:45 AM – 12:00 PM Tokyo MuleSoft Meetup at Tokyo!! Welcome everyone feel free to join(this event will only be provided in Japanese) 第5回目のMuleSoft Meetup Tokyoのオンライン開催となります!! 開発者 / アーキテクト / ITプロフェッショナル 同士でMuleSoftやAPI/Integrationのナレッジや経験を共有しましょう。 参加される方は上部にある[RSVP]ボタンで参加登録を行なって下さい。 [ご注意]: RSVPボタンをから登録をするだけで、参加登録は完了しています。参加登録の後に「Become a Featured Atten
こんばんは。ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。 qiita.com 初日なのでゆるふわな話をしましょう。 何の話か もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。 社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた 認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS— greenspa (@greenspa) 2020年9月28日 このbotに対する思うところはもう良いです。 今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAut
2020-08-21OpenAPI や Protocol Buffers のおかげで開発がかなり捗っている話こんにちは、インキュベーション本部エンジニアの加藤です。 主に CLINICS アプリの開発を担当しています。 はじめにCLINICS アプリの開発では OpenAPI や gRPC を利用しています。 OpenAPI と gRPC の間には何の関係もないのですが、どちらも API の仕様をスキーマ言語で記述するという点では共通しています。 今回はこの API スキーマが開発にもたらすメリットについて紹介していこうと思います。 API ドキュメントとしてのスキーマ定義既存のコードに機能を追加する際や修正を加える際に気にすることの多い部分は API の仕様ではないかと思います。 「リクエストやレスポンスはどのようなデータなのか」「この値は必須なのか、任意なのか」「データの型は数値なのか
社内向け勉強会で発表した内容です。 30分でと書いてありますが、実際には50分かかりました。 また時間の関係で結構省いたりしている箇所があります。 2020/07/19追記 ご指摘をいただいた箇所を多々修正いたしました。 特にOIDCとSPAの章が初版とは大幅に変更されていますのでご注意く…
※この投稿は米国時間 2020 年 4 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。 ほとんどのソフトウェア デベロッパーがご存じだと思いますが、API 設計には RPC と REST の 2 つの主要なモデルがあります。モデルに関係なく、ほとんどのモダン API は、なんらかの方法で同じ HTTP プロトコルにマッピングすることによって実装されます。また、RPC API 設計では、RPC モデルの範囲から外れずに HTTP から 1 つまたは 2 つのアイデアを採用することが一般的になっています。これにより、API 設計者に提示されるオプションの範囲が広がりました。この投稿ではこれらのオプションについて説明し、どれを選ぶか決める際に役立つガイダンスを提供します。 gRPC は RPC API を実装するためのテクノロジーで、HTTP 2.0 をその基盤
複数のウェブサービスを連携し、定型作業を自動化してくれるサービスはIFTTTやZapierが有名ですが、特定のサービス以外は使えなかったり、有料プランでしか使用できない機能があったりします。オープンソースで使える自動化サービス「n8n」は無料で利用でき、自社製ソフトのような他の自動化サービスでは未対応のサービスも自動化できるとのことなので、実際に使ってみました。 n8n.io - Workflow Automation https://n8n.io/ まずはn8nのホームページにアクセスします。 ホームページ下部へと進むとインストール方法が記載されていました。今回はWindows 10の機能の一つであるWSL上のUbuntuにn8nをインストールします。 n8nを動作させるにはNode.jsが必要なので、記事作成時点で最新の推奨バージョンのNode.jsをインストールしておきます。 Nod
サードパーティ製のツール本家からは上述のツールが提供されていますが、サードバーティ製の様々なツールが世の中には存在します。 エコシステムが成熟しているのもSwaggerを利用するメリットの1つですね。 https://openapi.tools/ 冒頭のとおり、このサードパーティ製のツールの中で実際に利用して良かったツールを3つご紹介したいと思います。 Stoplight Studiohttps://stoplight.io/studio/ 1つ目のツールは「Stoplight Studio」というAPI仕様を記載するためのGUIエディタとなります。 今までSwagger Editorを利用してYAMLを書いていたそこのみなさん、YAML筋力はもう必要ありません。 Design APIs 10x faster の謳い文句どおり、Stoplight Studioを使えばGUIで直感的に、高速
マイクロサービスにおけるWeb APIスキーマの管理 ─ GraphQL、gRPC、OpenAPIの特徴と使いどころ マイクロサービスにおける通信方式の選択について、おおた（ota42y）さんが、GraphQL・gRPC・OpenAPIといった主なWeb APIスキーマの管理の利点と使い分けを解説します。 近年流行しているマイクロサービスアーキテクチャにおいては、「どういった通信方式を選ぶか」が開発の効率やサービスの信頼性、パフォーマンスを大きく左右します。この記事では、GraphQL・gRPC・OpenAPIそれぞれの利点と適切な使い分けについて解説します。 マイクロサービスにおけるWeb API管理の重要性 Schema First DevelopmentとWeb API 人ではなくプログラムが処理できるよう管理する Web APIのインタフェース定義手法の比較 OpenAPI ─ R
Authlete とは？ Authlete は OAuth 2.0 および OpenID Connect を実装するための BaaS（Backend as a Service）です。Authlete が提供する Web API を使うことで、簡単に OAuth 2.0 および OpenID Connect の機能を簡単に実現できます。 なぜ Authlete が必要なのか？ サービスの Web API を実装する場合、サービスを提供する側は、OAuth 2.0（及び OpenID Connect）を実装すること必要となります。しかしながら、その実装は容易ではなく、実装に多くのリソース・時間が必要となります。また、個人データを管理すること自体、非常に慎重を要する作業です。限られた社内外のエンジニアのリソースを使い、これら課題を解決しつつ、競合よりも先にサービス提供することは、非常に大変です。
PKCE とは PKCE をご存知でしょうか？ これは、今から一年ほど前の 2015 年 9 月に RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients) として公開された仕様を指しています。認可コード横取り攻撃 (authorization code interception attack) への対策として策定されました。 細かい条件は幾つかありますが、スマートフォンで OAuth クライアントを作る場合は、クライアント側も認可サーバー側もこの仕様の実装が強く推奨されます。これを実装しておかないと、悪意のあるアプリケーションに認可コードを横取りされてしまい、結果、悪意のあるアプリケーションがアクセストークンを取得できてしまいます。 この仕様自体のちょっとした解説は、「OAuth & OpenID Connect 関連仕
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
