JWT アクセストークンからの個人情報漏洩 - Qiita
内包型アクセストークン、典型例としては JWT アクセストークンは、関連するデータを自身の内部に持っています。下記の条件が成り立つと、論理的な帰結として、そのようなアクセストークンから直接個人情報が漏洩します。 個人情報が含まれている 暗号化されていない ステートレス 意図しない者に盗まれる ここで「ステートレス」とは、「個人情報を保存するためのデータベースレコードを認可サーバー側に持たない」ことを意味しています。 もしもアクセストークンの実装が「内包型／暗号化されていない／ステートレス」であり、また、システムがクライアントアプリケーションに個人情報を提供する必要があるなら、当該システムは、アクセストークンに情報を埋め込むことを避け、個人情報を問い合わせるための Web API を提供すべきです。 ユーザー情報エンドポイント (OIDC Core Section 5.3) はそのような A
図解 JWS/JWE/JWT/IDトークン/アクセストークンの包含関係 - Qiita
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 全フローの図解と動画 - Qiita
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
OAuth 2.0 / OIDC 実装の新アーキテクチャー - Qiita
1.『On-Premises』パターンは、自分でマシンを用意し、そこに認可サーバーのソフトウェアをインストールして運用する方法です。 2.『Hosted Server』パターンは、マシンの物理的な運用はクラウドサービスにまかせ、そのマシン上に認可サーバーのソフトウェアをインストールして運用する方法です。 例えば AWS の EC2 インスタンスに OpenAM をインストールして運用する場合、このパターンに該当します。 3.『Hosted Service』パターンは、認可サーバー自体がクラウドサービスとして提供されるパターンです。 Okta や Auth0 がこのパターンに該当します。 4.『Semi-Hosted Service』パターンは、認可サーバーの主要機能を提供するサーバーが存在するものの、一部をローカルで実装するというパターンです。 Richer 氏が明示的に言及しているように
図解 X.509 証明書 - Qiita
はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書（１）』と『#5 X.509 証明書（２）』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名（前提知識） この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと
Java API 訴訟の件で私が Google よりも Oracle の肩を持つ理由 - Qiita
はじめに Java API を巡って Oracle と Google の訴訟が続いています。世間の論調を見ていると、「Oracle 対 Google」の構図を「プロプライエタリ対オープンソース」と位置付け、あたかも Google が正義の味方であるかのように扱っていますが、この件に関しては、私は逆の立場です。むしろ、「Google けしからん」と思っています。私がそう思う理由をここに書きます。 Java の互換性 Android が登場するずっと前から、業界の皆は、JCP (Java Community Process) に則り、協議の上 Java API の仕様を決めてきました。仕様を策定する際には、RI (Reference Implementation) (リファレンス実装) と TCK (Technology Compatibility Kit) (テスト群) も同時に用意します。
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
はじめに この文書では、OAuth 2.0 + OpenID Connect サーバーをゼロから一人で実装した開発者（私）が、得られた知見について書いていきます。基本的には「実装時に考慮すべき点」を延々と述べることになります。 そのため、この文書は、「素早く OAuth 2.0 + OpenID Connect サーバーを立てる方法」を探している方が読む類のものではありません。そのような情報をお求めの方は、「Authlete を使って超高速で OAuth 2.0 & Web API サーバーを立てる」を参照してください。そちらには、「何もない状態から認可サーバーとリソースサーバーを立て、アクセストークンの発行を受けて Web API をたたいて結果を得る」という作業を、所要時間 5 ～ 10 分でおこなう方法が紹介されています。 文書のバイアスについて 私は、OAuth 2.0 + Ope
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
