[B! RFC] hiroyukimのブックマーク

OAuth 2.0 におけるアクセストークン実装方法の検討 - 理系学生日記

OAuth 2.0 のプロバイダにおいて、アクセストークンをどのようにシステムで保持するのかっていうところを考えたり調べたりしていました。前提として、OAuth のトークンには以下の 2 種類の表現方法があります (RFC 6819 3.1. Tokens) Handle "opaque" トークンとも呼ばれるトークンの表現方法です。認可サーバー内部のデータ実体に対する単なる参照として表現され、トークンの文字列自体に意味はありません。トークンから参照を得るためには、トークンをキーにデータ実体を探して、必要な情報 (DB 上とかにある有効期限とか) を手に入れるという形になります。 Assertion トークン自体に意味を持たせるトークンの表現方法です。トークンから直接、必要な情報 (有効期限とか) を取得できます。アクセストークンに焦点を合わせると、トークンを発行するのは認可サーバ

hiroyukim 2017/12/01

oauth
RFC

リンク

OAuth 2.0の認可権限無効化の仕様 - 理系学生日記

OAuth 2.0 のプロバイダを作るんだったら、もしかして認可権限の取消画面も作らないといけないのかしら〜〜〜〜(ほげ〜〜〜〜)と思って調べてたら、その revoke の仕様も RFC で仕様化されていることを知りました。これにより、必ずしも取消画面を作らなくて良いということにはなりませんが、API として公開することは容易そうなので心をなでおろしています。 RFC 7009 - OAuth 2.0 Token Revocation OAuth 2.0 (RFC 6749) では認可サーバ側での認可権限の無効化について触れられていますが、RFC 7009 で触れられているのは、クライアントからの権限の無効化です。 Twitter における「アプリ連携」メニューでは、個々のアプリケーションに対して「許可を取り消す」というボタンが存在していますが、あれを仕様化したものと理解すれば良い。ト

hiroyukim 2017/12/01

oauth
RFC

リンク

UUID (version 4) における衝突確率を計算する - 理系学生日記

UUID というのは、全世界・全時間において一意性を持った識別子とされています。RFC 4122 の言葉を借りると、 A UUID is 128 bits long, and can guarantee uniqueness across space and time http://www.ietf.org/rfc/rfc4122.txt とされています。ですが、128 bit という有限長なんだから回試行すれば少なくとも 1 回は生成した UUID が衝突するということになります。UUID は万能じゃねーんだ。冷静になれ。 UUID ってのは一意性が「保証」されているわけじゃなく、「実用上は一意と見做せる」ということになります。ですから、衝突する確率というのは 0 にはなりません。じゃぁ、果たしてどのくらいの確率で衝突が発生するのか、計算してみましょう。計算のまえに結論を言う。回

hiroyukim 2015/06/16

リンク

HTTP/2から見えるTLS事情 - あどけない話

これは HTTP/2 アドベントカレンダー19日目の記事です。この記事はたくさんの資料を読んだ上で書きましたが、間違いとか勘違いとかがあるかもしれません。もしあれば、指摘していただけると幸いです。実質的に必須となったTLS HTTP/2は、HTTP/1.1と同じく、暗号化なし/ありのポートとして、80と443を使います。そのため、通信開始時にHTTP/1.1とHTTP/2をネゴシエーションするための仕組みが、HTTP/2で定められています。このように仕様としては暗号化なしのHTTP/2が定義されていますが、Firefox や Chrome が TLS を要求するために、実質的は暗号化ありが必須となっています。これは、米国の監視プログラムPRISMに代表される広域監視(pervasive surveillance)に対抗するために、IETFがさまざまな通信にプライバシの強化を要求する方