非技術者のためのOAuth認証(?)とOpenIDの違い入門【2023年版】
昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」（ユーザ認証）という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をしているサイトである伊
いますぐ使えるOpenID：第1回 OpenIDサービスを利用して，OpenIDの仕組みを理解する｜gihyo.jp … 技術評論社
いますぐ使えるOpenID 第1回OpenIDサービスを利用して、OpenIDの仕組みを理解する はじめに Yahoo!やYahoo!JapanがOpenIDサービスの提供を始めたり、MixiがOpenID対応を表明したりと、最近OpenIDについてのニュースを耳にするようになりました。 ところが、OpenIDという言葉は知っていても、実際に使ったことのある方はまだほとんどいないのではないでしょうか。 OpenIDによる認証を提供するサービスが増え、インターネット上でアカウントを持つ人の多くがOpenIDを利用できるようになっています。 さらにOpenIDを扱うPerlやRubyなどのライブラリも充実してきています。 このように、OpenIDを使うための環境は整ってきていると言えます。 そこで、本連載では実際にOpenIDを使ってみながら、その仕組みについて解説していきます。 同時に、
ブラウザー・WebViewが利用できないデバイスの課題とOAuth 2.0 Device Flow
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、ID連携黒帯 倉林 雅（@kura_lab）です。 昨年の「知っておきたい7つのID連携実装パターン」に続き今年も23日を担当することになりました！祝日も記事を投稿いたします！ 今年のAdventCalendarも「Yahoo! JAPANを支える技術」をテーマとしていますが、今回は少し先の未来をみすえて今後Yahoo! JAPANを支えることになるかもしれない新しい技術についてご紹介しようと思います。 すでにPCやスマホ上で認証を行いサービスを利用することは普通になりつつありますが、今後はテレビやゲーム機、ビデオカメラなどのデバイスでも認証や決済を利用したサービスが増えてくると思われます。Identity Provi
Oauth2.0, OpenID Connect, CSRF Study - Qiita
はじめに Developers Summit 2015 にてOpenID Japan エバンジェリストくらさんのセッションを聞いて、認証、認可について分かっていないことが分かりました。それから数か月、各リンクを巡ってStudyした内容をまとめます。 Study対象 モバゲ、Mixi、Facebook 各社の認証、認可シーケンスをまとめます。メジャーなセキュリティリスクとしてどんなものがあるかもまとめます。参考にした元ネタのリンクはページ以下になります。 参照URL DevSumi2014 ID Token: http://www.slideshare.net/kura_lab/devsumi201413c5 DevSumi2015 LoginSession管理 http://www.slideshare.net/kura_lab/openid-connect-and-login-cycle
OpenID ConnectでOpenID Auth 2.0ライクな動的UXを実現する方法 - r-weblife
こんばんは、ritouです。 忘れてしまっている方もおられるかと思いますが、いわゆるOpenID(Authentication 2.0)を使って認証要求を送るまでに、次のような処理が行われます。 ユーザーがOP選択 or 識別子の入力 RPがDiscoveryを行い、OP Endpoint URLを取得 RP,OP間でAssociation確立 これらの処理が行われることで、RPからみると「各OPへの事前登録なんてものは不要」、ユーザーからみると「自分が使っているOPが利用できる」、OPからみると「仕様に沿って実装すればどのRPでも使える」という仕様になっているわけです。 さて、仕様策定が進められているOpenID Connectですが、何度も言ってるとおり、OAuth 2.0ベースです。 OAuthというと、あらかじめClientの事前登録(Client ID/Secretの取得)が必要
OpenID Connect の JWT の署名を自力で検証してみると見えてきた公開鍵暗号の実装の話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 皆さん、OpenID Connect を使った Web 認証/認可システムを実装していて、「サードパーティのライブラリなんかに頼りたくない！」とか「署名を自分でパースして中身見てみたい！」とか「OpenSSL の RSA_verify 呼び出すだけじゃ物足りない！自分で $m = S^e \pmod{n}$ ってやって署名検証してみたい！」って思うことよくありますよね？ ここでは、暗号関連のライブラリを使用せず、OpenID Connect の JWT の署名を自力で 検証した際に調べた内容を備忘録としてまとめてみました。 普
OAuth & OpenID Connect 関連仕様まとめ - Qiita
はじめに OAuth や OpenID Connect に関連する仕様を紹介していこうと思います。 仕様はたくさんあるものの、ほとんどオプショナルです。しかし、「認可サーバーを実装する際は、RFC 6749 だけではなく、認可コード横取り攻撃への対抗策である RFC 7636 も実装すべきである」* という点は強調しておきたいと思います。 * 「PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと」という記事もご参照ください。 1. OAuth 2.0 (RFC 6749) OAuth 2.0 の仕様の本体は RFC 6749 (The OAuth 2.0 Authorization Framework) です。RFC 6749 の解説記事は世の中にたくさんあるので、ここでは要点だけ手短に紹介します。 RFC 6749 は、アクセストークンを発行
知っておきたい7つのID連携実装パターン
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、ID連携担当のくら（@kura_lab）です。 みなさんはYahoo! JAPANのWeb APIや認証、エンドユーザーの属性取得APIを実装したことがありますか。これらを利用するためにはYahoo! ID連携を用いてアクセストークンの取得やログインの実装が必要になります。単にアクセストークンの取得、ログインの実装といってもWebアプリ、ネイティブアプリにおいていろいろなパターンがあります。 SDKを用いる場合ほとんど意識せずに実装もできますが、提供するサービスのUXやシステムの環境に合わせてより最適な実装をするためには、それぞれの特徴を理解し適切なパターンを選択する必要があります。 Yahoo! ID連携はOAuth
第一回 認証基盤のこれからを支えるOpenID Connect | オブジェクトの広場
長年、組織領域とインターネット領域の境界で高価なセキュリティ製品を配備し、脅威から資産を守る手法が、世の中のデファクトスタンダードとして、多くの企業で採用されてきました。しかし、「モバイルデバイスの活用」、「クラウドサービス利用の浸透」、「ワークスタイルの変革」などのリクエストによって、その有効性は失われつつあります。また、これらのリクエストに対し、資産ごとにセキュリティ対策を実施すると、コストが非常に高くなる傾向があります。 第一回の本記事では、資産を守るための新たな境界である「アイデンティティ」に注目し、その境界を体現する認証連携方式について解説を行います。そして、数ある認証連携方式の中から2014年2月に標準化された「OpenID Connect」に注目して、仕様説明と有用性を解説したいと思います。 認証基盤のこれまで 認証基盤における認証対象アプリケーションとの連携実装方法を振り返
OpenID Connectはそんなに大変かね？ - OAuth.jp
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita ってのになんかフォローアップしろよ的なのが来たので。 ざっと読んだ感想としては、「OpenID Connect の OPTIONAL な機能全部実装したら、そら大変ですね」という感じ。（Authlete に関しては、OpenAM みたいな感じで使われる、OpenAM よりはるかに簡単に使える代わりに有料の何かなんだろうな、というイメージです） OAuth は必要なのか？ Basic 認証は死んだ。 ユーザー単位での API のアクセスコントロールがしたいです。 っていう前提で話すると、OAuth 以外まともな選択肢が無いんじゃないでしょうか。 OAuth の各種 Extension (RFC 6749 & 6750 以外にいろいろある) に関しては、適宜必要なのを実装すればいいんだけど
【第二弾】OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
はじめに 本記事は「OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る」の続編となります。保護リソースエンドポイント (protected resource endpoint)、いわゆる世の中でいうところの (狭義の) Web API の実装に関する話題がメインとなります。 1. もう一つの認可 1.1. アカウント属性文脈での認可 混乱を避けるため前記事では敢えて言及しませんでしたが、認可という言葉は別の文脈で使われることがあります。その文脈では、「誰が何の権限を持っているか (who has what permissions)」という情報を扱うために認可という言葉を使います。これは、OAuth の文脈での認可「誰が誰に何の権限を与えるか (who grants what permissions to whom)」とは異なります。厄介なことに、このど
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
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
YappoLogs: 誰でも簡単にOpenID 2.0なOPを作る方法 and CodeReposでOpenID(2.0対応)プロバイダの提供始めましたのお知らせ
誰でも簡単にOpenID 2.0なOPを作る方法 and CodeReposでOpenID(2.0対応)プロバイダの提供始めましたのお知らせ 先週のbuilder techtalkから俄然としてOpenIDが熱くなって来た今日この頃いかがお過ごしでしょうか。 先日参加して来たOpenID Hackathonの成果として、CodeReposがOpenIDのOpenID 2.0 Providerになりましたことをお知らせします。 CodeReposのアカウントをお持ちの方は、fastladderとかLIMLICとかのOpenIDでサインオンできるサービでOpenID URLをcoderepos.orgとだけ打ち込んでログインしてみて下さい。 2.0に対応していない所だったらhttp://coderepos.org/share/wiki/Committers/usernameとでも入れればいいと
mixi OpenIDで「マイミクシィだけの掲示板」を作ろう(Perl編) - ラーニング人生。
今日はmixi OpenIDという認証サービスが発表され、各所で報じられている。 ミクシィ、認証サービス「mixi OpenID」を提供--「mixi Platform」第1弾 mixiサービス企画部長に聞く、「プラットフォームを開放する理由」 「あなたのマイミクだけコメント可能な掲示板」といったウェブサービスが開発可能になった『mixi OpenID』 「mixiがOpenIDのOPになったからと言って何がどうなるというわけでもないでしょ」と思っていた人も、「マイミクシィ認証」「コミュニティ認証」という2つの仕様には少し驚いただろう。前者は「○○さんとマイミクシィであるか」、後者は「○○というコミュニティに入っているか」をそれぞれ証明するものだ。これらを使えば、単にmixiのユーザが使えるというだけに留まらない、人や関心でのつながりを生かしたアプリケーションを作れることになる。 以下のコ
OpenID認証2.0〜概論 | feedforce Engineers' blog
OpenID認証2.0の"概論"についての発表資料です 仕様の詳細部分については説明を省略しています XRI周辺についての説明も省略しています(力量不足につき) 仕様を把握しきれてはいないため、誤りが多く含まれている可能性があります 以下は、実際の発表で使用したスライドのPDFです。 - 発表資料(PDF) -- 1.1MB はじめに OpenID認証とは 特徴 「オープン」 「秘密情報の保護」 「分散的」 「HTTP」 「拡張」 用語 プロトコル概観 開始(Initiation) 正規化(Normarization) 発見(Discovery) 関連づけ(Association) 認証要求 エンドユーザーの認可 承認/却下 照合 実例 OP-Local Identifierで始める OP Identifierで始める HTMLのURLで始める 自前のYadis IDで始める セキュリティ
Final: OpenID Authentication 2.0 - 最終版
Abstract OpenID 認証は、エンドユーザが識別子 (Identifier) を管理していることを証明する方法を提供するものである。OpenID 認証を利用すれば、リライングパーティー (Relying Party、以下 RP) はエンドユーザのパスワードやメールアドレスなどにアクセスする必要がなくなる。 OpenID は、分散方式であり、RP や OpenID プロバイダ (OpenID Provider 、以下 OP) の承認・登録を行なう中央集権的な機関は存在しない。エンドユーザは利用する OP を自由に選択することができ、OP を変更しても自身の識別子をそのまま継続して利用することができる。 プロトコル自体は JavaScript や最新ブラウザを必要としないが、AJAX を利用しても認証 (authentication) の仕組みは上手く機能する。つまり、エンドユーザは
[Perl][OpenID] OpenID-Lite, その他 - Codin’ In The Free World
PerlのOpenIDクライアントであるOpenID-Liteをデベロッパリリースしました。 http://search.cpan.org/~lyokato/OpenID-Lite/ OpenID Enabledのruby-openidを参考に、OpenID2.0に準拠させてあります。 http://openidenabled.com/ 特徴 用語を2.0のspecに出来るだけ合わせた。 DH-SHA256, HMAC-SHA256の対応 Crypt::DH::GMPの採用(http://mt.endeworks.jp/d-6/2008/04/crypt-dh-gmp.html) XRI::Resolution::LiteによるXRI inameでのディスカバリのサポート(http://d.hatena.ne.jp/ZIGOROu/searchdiary?word=%2a%5bXRI%5d
OpenID認証の仕組み(想像)
■ Streamripperその後 先月仕掛けたStreamripperだが、ほったらかしにしておいたらこんなことに: % du -h ~/var/mp3 8.7G /home/sho/var/mp3 % df Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/hda1 38811816 31140276 7671540 81% / ぎゃ、もう10GB目前じゃん。RadioioJazzは64kbpsなので、128kbps換算にすると17GB相当である。ぜんぶ聴くのに何日かかるやら。つーかディスクの使用量が80%を超えてしまったので、しばらく休もう。 ■ OpenID認証の仕組み(想像) 今日のパワポ仕事に飽きたので、余勢で1枚。 なんとなく盛り上がっていることを察してVidentiry.org上にページを確保したのはいいが、何が面白いのかさっぱりわからない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンタープライズIT環境での OpenID Connect / SCIM の具体的実装方法 idit2014
