単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット＆ペーストアタックが可能だからです。 OAuth 認証？は、図１のような流れになります。 図１ OAuth 認証？の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A
本人確認と保険証～元オウム信者・斎藤容疑者の偽名保険証取得を考える
元オウムの平田容疑者を匿っていた斎藤明美容疑者(49)が、偽名で保険証を取得し、さらにそれを身分証明書として銀行口座を開設していたことが話題になっています[1]。これを受けて、私の twitter のタイムラインにもいろいろな声が出ています。その多くは、報道等と同様に、身分証明書が偽名で作れてしまったということを問題視していますが、一方ではそれは違うんでないの、という声もあります。そこで、ちょっと時間をとって整理しておきたいと思います。 今回問題になっているのは、斎藤容疑者が、大阪の整骨院で働くときに使っていな名前「吉川祥子」名義の健康保険証を取得し、これを使って銀行口座などを開設していたことです。 吉川祥子名義健康保険証。これは、協会けんぽのものだが、最初は政管健保の保険証として2000年8月に発行されている。 報道等によると、この健康保険証が最初に取得されたのは2000年8月[2]との
RESTに対する７つの誤解
海外に行くと、既に REST対SOAPの決着は付いている[1]（エンタープライズでもコンシューマでも）ように見えるのだが、日本国内で話していると、まだまだ混乱しているようだ。さながら2009年ごろの状況を見るようだ。そこで、今日は RESTに関わる誤解について、幾つか書いてみたいと思う。（殴り書きだが、あんまり聞かれるのでFAQとして。なお、以下の多くは、[2] サービスステーション：RESTの詳細でより詳細に書かれている。） 誤解1. RESTはマッシュアップ用のプロトコルで、サーバ間通信には適さないのではないか？ どこからこのような誤解が来ているのか理解に苦しむ。ひょっとすると、RESTはHTTPベースということが、ブラウザとWebサーバのやり取りという風に誤って捉えられているのかもしれない。 もちろん間違いである。 ブラウザとWebサーバとの間同様、サーバからサーバへの通信にもHTT
Specifications – 仕様集
現在作業中の仕様集 OpenID Connect 関連仕様 規格化済 OpenID Connect Core – OpenID Connect の基本部分 OpenID Connect Dynamic Registration – (Client を動的に登録するための仕様 OpenID Connect Discovery – Server Endpoint および設定情報を動的に発見するための仕様 例：Google https://accounts.google.com/.well-known/openid-configuration OAuth 2.0 Multiple Response Types –OAuth 2.0 response_type に OpenID Connect利用するものを追加. OpenID 2.0 to OpenID Connect Migration 1.0
非技術者のためのOAuth認証(?)とOpenIDの違い入門【2023年版】
昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」（ユーザ認証）という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をしているサイトである伊
OAuth Wrap Web App Profile まとめ
ちょっくら、OAuth Wrap Web App Profile をシーケンス図にまとめてみた。 ＃こんなの、spec自体に入っていてほしいんですが…。 注意点： wrap_client_id と wrap_client_secret は、事前に AuthzServer より WebAppClient に割り当てられています。 Access Token は、Resource と AuthzServer の間で取り決められた、Opaque な文字列で、Bearer Token （所持人払いToken）として機能します。 すべての通信はHTTPSで行うため、署名は必要ないということになっています。[*1]
.Nat Zone : 原口５原則とOpenID by Nat - .Nat Zone
「番号に関する原口５原則」というものが発表されている。 原則１ 国民の権利を守るためのであること 社会保障給付や所々の行政サービスの提供を適切に受ける国民の権利を守るための番号であり、重複なく、もれなく、正確かつ安全に付番を行う 原則２ 自らの情報を不正に利用・ストックされず、確認・修正が可能な、自己情報をコントロール出来る仕組みであること 自らの情報が不正に利用・ストックされることなく、また自らの情報にアクセスし、内容の確認・修正ができる（自己情報コントロール権） 原則３ 利用される範囲が明確な番号で、プライバシー保護が徹底された仕組みであること 自らの情報についてどのような行政機関がどのような目的で利用するのか明確な制度とするとともに、最新の暗号化技術により情報漏えい防止に万全を期し、分野をまたがる情報の名寄せを防ぐ。 原則４ 費用が最小で、確実かつ効率的な仕組みであること 既存インフ
.Nat Zone : 国民ID配布の課題 by Nat - .Nat Zone
政府の効率化のためには、住基ネットを使って国民IDをとっとと配れば良いと言う議論がある。 たしかに、安全に正確に漏れ無く重複なくコスト効率的に配れるのであれば、配れば良いとも思うが、実際にやろうとすると、そんなに簡単なことではない。 「原口５原則とOpenID」の「原則１」のところにも書いたが、振るにあたっては２つ課題がある。 課題１： 正確性の課題 一つ目は、住基ネットデータベースの正確性の問題である。 住基ネットは各市町村で入力している。いくら正確を記したとしても、人がやるのだから間違いはある。その運用水準がどのレベルなのかという課題がまずある。 よしんば、入力運用が完璧だったとしても、入力するためのデータ作成、すなわち転出・転入手続はどうだろうか？ ネットで検索したところ、転出・転入手続に必要な書類は、 転出証明書の取得 印鑑 運転免許証、パスポート、身体障害者手帳など写真付きの身分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Draft: OpenID Artifact Binding 1.0 - Draft07