はじめに Authlete (オースリート) という OAuth / OpenID Connect の商用実装を 2014 年から開発し続けています。本記事公開時点 (2024 年 12 月) で開発開始から 10 年以上が経過しています。 OpenID Foundation という世界標準仕様策定団体が コンフォーマンススイート (互換性確認テスト群) の開発に Authlete を事実上のリファレンス実装として用いている事実が示すように、Authlete は数多くの標準仕様をサポートしており、実装品質はとても高いです。 特に、世界各国の API エコシステムで採用されている FAPI (ファピ) と呼ばれる高セキュリティプロファイルのサポートでは世界トップを走っており、高いセキュリティを必要とする国内外の金融機関で Authlete が採用されています。世界最大のデジタル銀行であるヌー

はじめに 34 歳のとき、勤めていた会社の経営が傾き早期退職を促されたのを契機に独立しました。その後、41 歳で Authleteオースリート 社を設立しました。諸般の事情で現在も Authlete 社の代表取締役という肩書きを持っていますが、経営者的な仕事は他の人に任せ (参照: シリコンバレーのプロフェッショナル CEO を迎えて米国市場に挑戦する日本のスタートアップの話)、50 歳目前の現在もプログラマとしてコードを書き続けています。 Authlete 社設立 (2015 年 9 月) から 8 年半弱経過したものの、まだまだ小さな会社で道半ばであるため、起業家として何か語るのは時期尚早ではあるものの、軽い体調不良が長引く中、『自分のエンジニアとしてキャリアを振り返ろう！』という記事投稿キャンペーンを見かけ、生きているうちに子供世代のエンジニアの方々に何か書き残しておこうと思い、文章

はじめに 34 歳のとき、勤めていた会社の経営が傾き早期退職を促されたのを契機に独立しました。その後、41 歳で Authleteオースリート 社を設立しました。諸般の事情で現在も Authlete 社の代表取締役という肩書きを持っていますが、経営者的な仕事は他の人に任せ (参照: シリコンバレーのプロフェッショナル CEO を迎えて米国市場に挑戦する日本のスタートアップの話)、50 歳目前の現在もプログラマとしてコードを書き続けています。 Authlete 社設立 (2015 年 9 月) から 8 年半弱経過したものの、まだまだ小さな会社で道半ばであるため、起業家として何か語るのは時期尚早ではあるものの、軽い体調不良が長引く中、『自分のエンジニアとしてキャリアを振り返ろう！』という記事投稿キャンペーンを見かけ、生きているうちに子供世代のエンジニアの方々に何か書き残しておこうと思い、文章

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 から

SD-JWTは、Selective Disclosure (選択的開示) を実現するためのフォーマットの一つです。Camenisch-Lysyanskaya Signatures (論文:Signature Schemes and Anonymous Credentials from Bilinear Maps) など、競合する仕様は幾つかあるものの、2022年に行われたクレデンシャル・プロファイル比較 (比較表) やIDUnionのハッカソンの経験を経て、SD-JWTを推進する流れができつつあります。例えば、European Digital IdentityはEuropean Union Digital Identity Wallet (EUDI Wallet) のArchitecture and Reference Framework (ARF) として示した文書において、SD-JWT

本稿は GitHub Docs の "Authorizing OAuth Apps" ページに書かれている情報に基づいています。英語版はこちら → "Spec Violations in GitHub OAuth Implementation and Security Considerations" 仕様違反箇所 認可リクエストの response_type リクエストパラメーターがない。当パラメーターは必須である。RFC 6749 (The OAuth 2.0 Authorization Framework) Section 4.1.1 (Authorization Request) 参照。 トークンレスポンスのデフォルトフォーマットが application/x-www-form-urlencoded のようである。フォーマットは常に application/json でなければならな

ID 連携フローの説明 1 ウェブブラウザを使い、ウェブサービスのログインページにアクセスします。 2 ウェブサービスはログインページを生成し、ウェブブラウザに返します。ウェブサービスが外部のアイデンティティプロバイダ（IdP）との ID 連携をサポートしていれば、ログインページ内に ID 連携を開始するためのリンクが埋め込まれます。 3 ID 連携を開始するためのリンクをクリックします。 4 ID 連携開始の要望を受けたウェブサービスは、対象となる IdP への認証リクエスト（OpenID Connect Core 1.0 Section 3.1.2.1. Authentication Request）を作成します。 認証リクエストの形式は、リクエストパラメーター群を含めた、IdP の認可エンドポイント（RFC 6749 Section 3.1. Authorization Endpoi

内包型アクセストークン、典型例としては JWT アクセストークンは、関連するデータを自身の内部に持っています。下記の条件が成り立つと、論理的な帰結として、そのようなアクセストークンから直接個人情報が漏洩します。 個人情報が含まれている 暗号化されていない ステートレス 意図しない者に盗まれる ここで「ステートレス」とは、「個人情報を保存するためのデータベースレコードを認可サーバー側に持たない」ことを意味しています。 もしもアクセストークンの実装が「内包型／暗号化されていない／ステートレス」であり、また、システムがクライアントアプリケーションに個人情報を提供する必要があるなら、当該システムは、アクセストークンに情報を埋め込むことを避け、個人情報を問い合わせるための Web API を提供すべきです。 ユーザー情報エンドポイント (OIDC Core Section 5.3) はそのような A

JWS/JWE/JWT/IDトークンの包含関係 JWS (JSON Web Signature) と JWE (JSON Web Encryption) の直列化方法には、それぞれ JSON 形式とコンパクト形式がある。 JWT (JSON Web Token) は JWS か JWE だが、いずれにしてもコンパクト形式である。仕様でそう決まっている。 仕様により、ID トークンには署名が必要なので、ID トークンは JWS もしくは「JWS を含む JWE」という形式をとる。 ID トークンは「JWE を含む JWS」という形式はとらない。なぜなら、仕様により、ID トークンを暗号化する際は「署名してから暗号化」という順番と決まっているため。 アクセストークン/JWT/IDトークンの包含関係 アクセストークンの実装が JWT だとは限らない。 仕様により、ID トークンは必ず JWT で

クライアントアプリケーションと認可サーバーがあります。 クライアントアプリケーションは複雑な認可リクエストを抱えています。 もしも認可サーバーが『OAuth 2.0 Pushed Authorization Requests』（通称 PAR）をサポートしているなら、サーバーは『Pushed Authorization Request Endpoint』を公開しています。 クライアントアプリケーションは、Pushed Authorization Request Endpoint で複雑な認可リクエストを認可サーバーに登録します。 応答として、登録された認可リクエストを表す『Request URI』が発行されます。 クライアントアプリケーションは Web ブラウザを介して認可サーバーの認可エンドポイントに認可リクエストを送信します。クライアントは複雑な認可リクエストを送る必要はありません。かわ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに OAuth 2.0 の認可レスポンスは、登録済みの『リダイレクト URI』宛に返却されます。詳細は『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』を参照してください。 複数のリダイレクト URI が登録されている場合、どのリダイレクト URI に認可レスポンスを返して欲しいかを、認可リクエスト時に指定する必要があります。この目的のために、redirect_uri リクエストパラメーターが用いられます。 認可サーバーは、redirect_uri リクエストパラメーターで指定された URI が、事前登録されたリダ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに この記事は、JAR と呼ばれる技術仕様『RFC 9101 The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)』に関する実装者の覚書です。(英語版はこちら) OpenID Connect Core 1.0 (OIDC Core) と JAR の間には幾つか衝突する部分があります。既存の認可サーバーだけでなく OpenID 互換性検査スイートにさえも影響を及ぼすため、OAuth コミュニティーはそれらの破壊的変更について長い間論争を続けました。 衝突する部分とは何か？それらはどのように解決されたのか？ JAR 仕様の未来の読者や実装者のため、この記事はそれらについて記述します。 JAR とは？ JAR とは、認可リクエストパラメーター群を一つの署名付き JWT にまとめるための仕

RFC 6749 (The OAuth 2.0 Authorization Framework) で定義されている 4 つの認可フロー、および、リフレッシュトークンを用いてアクセストークンの再発行を受けるフローの図解及び動画です。動画は YouTube へのリンクとなっています。 English version: Diagrams And Movies Of All The OAuth 2.0 Flows 追記 (2019-07-02) 認可決定エンドポイントからクライアントに認可コードやアクセストークンを渡す方法については、別記事『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』で解説していますので、ご参照ください。 追記（2020-03-20） この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！ 1. 認可コードフロー RF

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書（１）』と『#5 X.509 証明書（２）』で解説しているので、動画解説のほうがお好みであればそちらをご参照くださ

この仕様は、悪い人がアクセストークンを盗んだとしても、それだけでは API に対する不正アクセスができないようにするための仕組みです。 従来は、クライアントアプリケーションがアクセストークンを提示して API にアクセスしてきたとき、そのアクセストークンが有効であれば、API アクセスは許可されていました。しかし、DPoP などの Proof of Possession（PoP）の仕組みを用いると、アクセストークンを提示しているクライアントがそのアクセストークンの正当な所有者かどうか（＝アクセストークンの発行を受けたクライアントと同一かどうか）もチェックされるようになり、アクセストークンの正当な所有者とみなされない場合は API アクセスが拒否されるようになります。 PoP の方法として RFC 8705 の Section 3 で定義されている方法（通称 MTLS）が使えるのであればそち

HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "device_code": "GmRhmhcxhwAzkoEqiMEg_DnyEysNkuNhszIySk9eS", "user_code": "WDJB-MJHT", "verification_uri": "https://example.com/device", "verification_uri_complete": "https://example.com/device?user_code=WDJB-MJHT", "expires_in": 1800, "interval": 5 } User Code（正式には End-User Verification Code）と Device Code（正式には Device Verifica

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Authlete（オースリート）社主催の勉強会『いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい』（2020 年 1 月 31 日（済）, 2020 年 2 月 21 日（中止））の内容がてんこ盛り過ぎるため、予習・復習用の情報を書き出そうと思います。 追記 2020 年 1 月 31 日の勉強会の資料と動画（字幕付き）を公開しました！ OAuth / OIDC 勉強会参加者は、OAuth 2.0（オーオース）と OpenID Connect（オープンアイディー・コネクト）の基本を知っている

はじめに 2018 年 11 月 30 日に『犯罪による収益の移転防止に関する法律』（犯罪収益移転防止法／犯収法）を改正する命令が公表されました。この改正で「オンラインで完結する自然人の本人特定事項の確認方法の追加」が行われ、eKYC（electronic Know Your Customer）の根拠法となりました。 そして、当改正から約一年後の 2019 年 11 月 11 日、世界標準仕様策定団体である OpenID Foundation から『OpenID Connect for Identity Assurance 1.0』という技術仕様の第一版が公開されました。また、これを受けて同団体内に新たに『eKYC and Identity Assurance ワーキンググループ』が設置されました。それから約半年後の 2020 年 5 月 19 日には、同仕様の第二版が公開されました。 犯

はじめに 『Resource Indicators for OAuth 2.0』という仕様を実装したので、それについて書こうと思います。 Finished implementing "Resource Indicators for #OAuth 2.0". Now, by using #Authlete 2.2, endpoints defined in RFC 6749, RFC 8628 and CIBA can recognize the 'resource' request parameters and tokens become audience-restricted. It took me nearly 2 days to implement the spec. — Taka@Authlete, BaaS for OAuth 2.0 & OpenID Connect (@dar

逆に、RFC 6749 以外で定義されている認可フローをサポートする場合、新たに別のエンドポイントの実装が必要になることがあります。例えば CIBA（Client Initiated Backchannel Authentication）では**バックチャネル認証エンドポイント（backchannel authentication endpoint）、デバイスフロー（RFC 8628）ではデバイス認可エンドポイント**（device authorization endpoint）の実装が求められます。 この記事では、認可エンドポイントとトークンエンドポイントを実装します。サポートする認可フローは認可コードフローのみ、サポートするクライアント・タイプはパブリックのみとします。 2. 注意点 下記の理由、および書かれていないその他の理由により、本実装は商用利用には適していません。 セキュリティ

サーバーは、受け取ったクライアント証明書の主体識別情報が事前登録されているものと一致することを確認し、もってクライアント認証とします。 このクライアント認証方式には tls_client_auth という名前が与えられています（MTLS, 2.1.1. PKI Method Metadata Value）。 なお、クライアント証明書には OAuth 2.0 の文脈におけるクライアント ID は入っていないので、クライアント証明書だけではクライアントを特定することはできません。そのため、クライアント証明書を用いるクライアント認証をおこなう際は、別途クライアント ID をリクエストに含める必要があります。通常は client_id リクエストパラメーターが使用されます。 1.8. self_signed_tls_client_auth クライアント証明書を用いるクライアント認証において、PKI

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事では、OAuth 2.0 のアクセストークンの実装に関する考察を行います。本記事の執筆者本人による動画解説も『OAuth & OIDC 勉強会 【アクセストークン編】』で公開しておりますので、併せてご参照ください。 English version of this article is here → "OAuth Access Token Implementation". 1. アクセストークン実装方法の分類 OAuth のアクセストークン※１の実装方法は認可サーバーの実装依存です。 実装依存ではありますが、RFC 67

注記: 2021 年 3 月に公開された FAPI 1.0 最終版に対応するため、本記事の内容を大幅に更新しました。タイトルも『世界最先端の API セキュリティー技術、実装者による『FAPI（Financial-grade API）』解説』から『実装者による Financial-grade API (FAPI) 解説』に変更しました。本記事の英語版は "Financial-grade API (FAPI), explained by an implementer" です。 はじめに Financial-grade API（通称 FAPI; ファピ）は、OpenID Foundation の Financial-grade API ワーキンググループが策定した技術仕様です。OAuth 2.0 と OpenID Connect（以降 OIDC）を基盤とし、より高い API セキュリティーを必

はじめに この記事では、『OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0』、通称『CIBA Core』の解説をおこなう。（CIBA は『シーバ』と読む） OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0 CIBA Core は 2018 年 12 月 14 日に Public Review 期間に入った（アナウンス）。スケジュール通りに進めば、2019 年 2 月初旬には Implementer's Draft として承認される※。 ※：2019 年 2 月 4 日に承認のアナウンスがあった。 Public Review に先立ち、実装者の視点からいろいろ突っ込みを入れておいたので、実装上大

はじめに この記事では、OAuth 2.0 の認可サーバーが返す認可レスポンスと、それに伴うリダイレクト処理について説明します。 動画解説のほうがお好みであれば、オンライン勉強会『OAuth & OIDC 勉強会 【認可リクエスト編】』の『3. リダイレクション』をご覧ください。 認可レスポンス RFC 6749（The OAuth 2.0 Authorization Framework）には、アクセストークン発行フローが幾つか定義されています（参考：OAuth 2.0 全フローの図解と動画）。 それらのうち、認可コードフロー（RFC 6749, 4.1. Authorization Code Grant）とインプリシットフロー（RFC 6749, 4.2. Implicit Grant）では、クライアントアプリケーションが Web ブラウザを介して認可サーバーの認可エンドポイント（RFC

はじめに Laravel ユーザーに朗報です！ 『authlete/authlete-laravel』ライブラリをリリースしました！ このライブラリにより、OpenID Certification 取得済みの認可エンジン『Authlete』をバックエンドに用いた本格的な認可サーバー・OpenID プロバイダーの開発が、Laravel で可能となりました！ この記事では、PHP 用のフレームワークの一つである Laravel を用いて、OAuth 2.0 と OpenID Connect に対応する認可サーバー（兼 OpenID プロバイダー）とリソースサーバーを実装する方法を紹介します。実装には、PHP 共通の authlete/authlete ライブラリと Laravel 専用の authlete/authlete-laravel ライブラリを使用します。 なお、実例として Larav

はじめに OAuth 2.0 と OpenID Connect をサポートする認可サーバー兼 OpenID プロバイダーの C# 実装である『csharp-oauth-server』、及び、OpenID Connect Core 1.0 の「5.3. UserInfo Endpoint」で定義されているユーザー情報エンドポイントの実装を含むリソースサーバーの C# 実装である『csharp-resource-server』を紹介します。 English version: “OAuth 2.0 and OpenID Connect implementation in C# (Authlete)” 1. アーキテクチャー csharp-oauth-server と csharp-resource-server は『authlete-csharp』ライブラリ（NuGet パッケージ 『Authl