サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Appleイベント
qiita.com/TakahikoKawasaki
はじめに 34 歳のとき、勤めていた会社の経営が傾き早期退職を促されたのを契機に独立しました。その後、41 歳で Authleteオースリート 社を設立しました。諸般の事情で現在も Authlete 社の代表取締役という肩書きを持っていますが、経営者的な仕事は他の人に任せ (参照: シリコンバレーのプロフェッショナル CEO を迎えて米国市場に挑戦する日本のスタートアップの話)、50 歳目前の現在もプログラマとしてコードを書き続けています。 Authlete 社設立 (2015 年 9 月) から 8 年半弱経過したものの、まだまだ小さな会社で道半ばであるため、起業家として何か語るのは時期尚早ではあるものの、軽い体調不良が長引く中、『自分のエンジニアとしてキャリアを振り返ろう!』という記事投稿キャンペーンを見かけ、生きているうちに子供世代のエンジニアの方々に何か書き残しておこうと思い、文章
プレゼン資料はダニエルのウェブサイトの投稿 "SD-JWT Reference Implementation at the OpenWalletFoundation (OWF)" で公開されています。彼は2023年4月からAuthlete社のメンバーになったのでプレゼン資料にAuthleteのロゴが載っています。 SD-JWTは、Selective Disclosure (選択的開示) を実現するためのフォーマットの一つです。Camenisch-Lysyanskaya Signatures (論文:Signature Schemes and Anonymous Credentials from Bilinear Maps) など、競合する仕様は幾つかあるものの、2022年に行われたクレデンシャル・プロファイル比較 (比較表) やIDUnionのハッカソンの経験を経て、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 ブラウザを介して認可サーバーの認可エンドポイントに認可リクエストを送信します。クライアントは複雑な認可リクエストを送る必要はありません。かわ
はじめに OAuth 2.0 の認可レスポンスは、登録済みの『リダイレクト URI』宛に返却されます。詳細は『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』を参照してください。 複数のリダイレクト URI が登録されている場合、どのリダイレクト URI に認可レスポンスを返して欲しいかを、認可リクエスト時に指定する必要があります。この目的のために、redirect_uri リクエストパラメーターが用いられます。 認可サーバーは、redirect_uri リクエストパラメーターで指定された URI が、事前登録されたリダイレクト URI のいずれかに一致するかどうかを確認します。この「一致」について、「前方一致のサポートは可能か?」との質問を受けることが稀にあるので、見解を述べさせていただこうと思います。 OpenID Connect のケース ID トークンを発行するなど
はじめに Spring Security プロジェクトは、認可サーバーの実装を今後サポートしない旨、2019 年 11 月 14 日付の『Spring Security OAuth 2.0 Roadmap Update』でアナウンスしました。しかしその後、一部の有志が Spring の認可サーバー実装プロジェクト『Spring Authorization Server』を開始しました。この記事は、そのプロジェクトに対する警鐘となります。 OAuth 2.0 Multiple Response Type Encoding Practices 2012 年 10 月の RFC 6749(The OAuth 2.0 Authorization Framework)のリリースから 1 年 4 ヶ月後の 2014 年 2 月、OAuth 2.0 Multiple Response Type Enco
はじめに この記事は、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 にまとめるための仕
はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書(1)』と『#5 X.509 証明書(2)』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名(前提知識) この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと
はじめに DPoP(ディーポップ)という仕様を紹介します。 OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP) この仕様は、悪い人がアクセストークンを盗んだとしても、それだけでは API に対する不正アクセスができないようにするための仕組みです。 従来は、クライアントアプリケーションがアクセストークンを提示して API にアクセスしてきたとき、そのアクセストークンが有効であれば、API アクセスは許可されていました。しかし、DPoP などの Proof of Possession(PoP)の仕組みを用いると、アクセストークンを提示しているクライアントがそのアクセストークンの正当な所有者かどうか(=アクセストークンの発行を受けたクライアントと同一かどうか)もチェックされるようになり、アク
はじめに 2019 年 8 月に公開された RFC 8628(OAuth 2.0 Device Authorization Grant)、いわゆる『デバイスフロー』(Device Flow)について説明します。 デバイスフローは、RFC 6749(The OAuth 2.0 Authorization Framework)で定義されているフロー群と同様に、アクセストークンを発行するためのフローです。 そもそも別途新たにフローを作成した理由ですが、それについては仕様書の冒頭に次のように書かれています。 The OAuth 2.0 device authorization grant is designed for Internet-connected devices that either lack a browser to perform a user-agent-based author
はじめに Authlete(オースリート)社主催の勉強会『いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい』(2020 年 1 月 31 日(済), 2020 年 2 月 21 日(中止))の内容がてんこ盛り過ぎるため、予習・復習用の情報を書き出そうと思います。 追記 2020 年 1 月 31 日の勉強会の資料と動画(字幕付き)を公開しました! OAuth / OIDC 勉強会参加者は、OAuth 2.0(オーオース)と OpenID Connect(オープンアイディー・コネクト)の基本を知っていることが前提となります。 OAuth 2.0 は「アクセストークンを発行する仕組み」です。その中心となる仕様は RFC 6749 です。詳細については『一番分かりやすい OAuth の説明』と『OAuth 2.0 全フローの図解と動画』をご参照ください。 Op
はじめに 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. 注意点 下記の理由、および書かれていないその他の理由により、本実装は商用利用には適していません。 セキュリティー上必須
はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。
はじめに この記事では、OAuth 2.0 のアクセストークンの実装に関する考察を行います。本記事の執筆者本人による動画解説も『OAuth & OIDC 勉強会 【アクセストークン編】』で公開しておりますので、併せてご参照ください。 English version of this article is here → "OAuth Access Token Implementation". 1. アクセストークン実装方法の分類 OAuth のアクセストークン※1の実装方法は認可サーバーの実装依存です。 実装依存ではありますが、RFC 6749 の『1.4. Access Token』にある次の記述が示唆するように、 The token may denote an identifier used to retrieve the authorization information or may
注記: 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 6749, 3
はじめに 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
$ git clone https://github.com/authlete/spring-oauth-server $ cd spring-oauth-server $ vi authlete.properties $ mvn spring-boot:run $ git clone https://github.com/authlete/spring-resource-server $ cd spring-resource-server $ vi authlete.properties $ mvn spring-boot:run
はじめに OpenID Connect は OAuth 2.0 を拡張する形で策定されました。 OAuth 2.0 はアクセストークン発行手順に関する仕様で、RFC 6749(The OAuth 2.0 Authorization Framework)で定義されています(参考:一番分かりやすい OAuth の説明)。 一方、OpenID Connect は ID トークン発行手順に関する仕様で、主要部分は OpenID Connect Core 1.0 で定義されています(参考:一番分かりやすい OpenID Connect の説明)。 RFC 6749 は認可エンドポイントという Web API を定義しています。 この API は必須のリクエストパラメーターとして response_type を要求します。 OpenID Connect は、この response_type の仕様を拡
1.『On-Premises』パターンは、自分でマシンを用意し、そこに認可サーバーのソフトウェアをインストールして運用する方法です。 2.『Hosted Server』パターンは、マシンの物理的な運用はクラウドサービスにまかせ、そのマシン上に認可サーバーのソフトウェアをインストールして運用する方法です。 例えば AWS の EC2 インスタンスに OpenAM をインストールして運用する場合、このパターンに該当します。 3.『Hosted Service』パターンは、認可サーバー自体がクラウドサービスとして提供されるパターンです。 Okta や Auth0 がこのパターンに該当します。 4.『Semi-Hosted Service』パターンは、認可サーバーの主要機能を提供するサーバーが存在するものの、一部をローカルで実装するというパターンです。 Richer 氏が明示的に言及しているように
はじめに 過去三年間、技術者ではない方々に OpenID Connect(オープンアイディー・コネクト)の説明を繰り返してきました※1。 その結果、OpenID Connect をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1:Authlete 社の創業者として資金調達のため投資家巡りをしていました(TechCrunch Japan:『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』)。 2017 年 10 月 23 日:『OpenID Connect 全フロー解説』という記事も公開したので、そちらもご参照ください。 説明手順 (1)「こんにちは! 鈴木一朗です!」 (2)「え!? 本当ですか? 証明してください。」 (3)「はい! これが私の名刺です!
次のページ
このページを最初にブックマークしてみませんか?
『@TakahikoKawasakiのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く