OAuth アクセストークンの実装に関する考察 - Qiita
はじめに この記事では、OAuth 2.0 のアクセストークンの実装に関する考察を行います。本記事の執筆者本人による動画解説も『OAuth & OIDC 勉強会 【アクセストークン編】』で公開しておりますので、併せてご参照ください。 English version of this article is here → "OAuth Access Token Implementation". 1. アクセストークン実装方法の分類 OAuth のアクセストークン※１の実装方法は認可サーバーの実装依存です。 実装依存ではありますが、RFC 6749 の『1.4. Access Token』にある次の記述が示唆するように、 The token may denote an identifier used to retrieve the authorization information or may
OAuth & OpenID Connect の不適切実装まとめ - Qiita
はじめに 世の中の OAuth & OpenID Connect の不適切実装の事例をリストしています。公式ドキュメントに「ドラフト段階の仕様をサポート」と断り書きが書いてあっても、最終仕様に違反している場合はリストしています。内容は適宜更新していきます。OAuth & OpenID Connect を実装する際の注意事項として参照していただければと思います。 仕様書を読むのは面倒だけど、OAuth & OpenID Connect をちゃんと実装しないといけない立場にある方は、是非 Authlete の使用を検討してください。(by Authlete 創業者) 事例 1. リダイレクト URI を正しく検証していない John Bradley 氏の記事「Covert Redirect and its real impact on OAuth and OpenID Connect」を参照し
一番分かりやすい OAuth の説明 - Qiita
はじめに 過去三年間、技術者ではない方々に OAuth（オーオース）の説明を繰り返してきました※1,※2。その結果、OAuth をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。Authlete アカウント登録はこちら！ ※2：そして２回目の資金調達！→『AUTHLETE 凸版・NTTドコモベンチャーズ・MTIからプレシリーズA資金調達』(2018 年 2 月 15 日発表) 説明手順 （１）ユーザーのデータがあります。 （２）ユーザーのデータを管理するサーバーがあります。これを『リソースサーバ
実装者による CIBA 解説 - Qiita
はじめに この記事では、『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 に先立ち、実装者の視点からいろいろ突っ込みを入れておいたので、実装上大
PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと - Qiita
PKCE とは PKCE をご存知でしょうか？ これは、今から一年ほど前の 2015 年 9 月に RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients) として公開された仕様を指しています。認可コード横取り攻撃 (authorization code interception attack) への対策として策定されました。 細かい条件は幾つかありますが、スマートフォンで OAuth クライアントを作る場合は、クライアント側も認可サーバー側もこの仕様の実装が強く推奨されます。これを実装しておかないと、悪意のあるアプリケーションに認可コードを横取りされてしまい、結果、悪意のあるアプリケーションがアクセストークンを取得できてしまいます。 この仕様自体のちょっとした解説は、「OAuth & OpenID Connect 関連仕
一番分かりやすい OpenID Connect の説明 - Qiita
はじめに 過去三年間、技術者ではない方々に OpenID Connect（オープンアイディー・コネクト）の説明を繰り返してきました※1。 その結果、OpenID Connect をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。 2017 年 10 月 23 日：『OpenID Connect 全フロー解説』という記事も公開したので、そちらもご参照ください。 説明手順 （１）「こんにちは！ 鈴木一朗です！」 （２）「え！？ 本当ですか？ 証明してください。」 （３）「はい！ これが私の名刺です！
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
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) (テスト群) も同時に用意します。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
