OAuth PKCEがRFC7636として発行されました。
私とJohn Bradley(Ping)とNaveen Agarwal(Google)が共著者としてクレジットされている「OAuth PKCE（ピクシー）」 が、[RFC 7636] として発行されました。元々はOAuth SPOP (Symmetric Proof of Posession)と言っていたものですが、Symmetricに限らない形に拡張したため、Proof Key for Code Exchange (PKCE、ピクシー＝妖精）と名を改めて現在に至っています。 この規格はOAuth 2.0 [RFC6749]のPublic Client の Code Interception Attack 脆弱性に対応するもので、ephemeral keyを生成して、これを使ったProof of Possession of Key をします。RFC6749と後方互換性がありますし実装も簡単
RPはエンドユーザーのどのIdentityに対して一意なユーザーと認識するべきか
IwamotoTakashiさんの日記（ここやここやここやここ）やZIGOROuさんの日記で触れられていたので、ちょいとばかし、整理。 お題は、「RPはエンドユーザーのどのIdentityに対して一意なユーザーと認識するべきか」 OpenID 1.1 [Request] openid.identity := Claimed Identifier Claimed Identifier は、ユーザが持っていると主張する 識別子で、長期間変わらないことが期待されるもの。 [Response] openid.identity := Verified Identifier したがって、delegate している場合は、delegate先で 確認したIDになる。 Delegate 先は、しょっちゅう変わることがありえる。 したがって、RPでキーとして使えるのは、Request の Openid.ide
「番号」制度の情報連携基盤は複雑か？
国民ID制度、「番号」制度（あやまって、共通番号制度とも呼ばれることがあるが）のコンテキストで語られるシステム基盤に、「情報連携基盤」とよばれるものがあります。下の図（内閣官房情報連携基盤技術ワーキンググループ中間報告より）のオレンジの箱がそれです。 （図1）番号制度における符号連携のイメージ どうもここの部分が、各界の「識者」の方々には、「複雑怪奇」「動かない」とか「ベンダーを利するだけ」などと何かと評判が悪いようです。 実際には、このような仕組みを入れることは、プライバシーやセキュリティの観点から不可欠で、これの理由も延々と報告書やら議事録やらに収録されているのですが、私の観点としては、（やり方に気をつけさえすれば）そもそも「複雑」ですらないので、まずそのことについて書きたいと思います。 インターネットって複雑怪奇で動かないシステム？ そこで、質問。 今、この記事をご覧になっているあな
非技術者のためのOAuth認証(?)とOpenIDの違い入門【2023年版】
昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 Youtube版 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」（ユーザ認証）という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をして
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
