Web APIにおける認可の現状確認 2019 春 - 解せぬ日記
最近Web APIの認可について思いを馳せる機会があったのだけど、どの方法で認可を実装するのがスタンダードなのか、そもそもそんなものは最初からないのか、よく分からなくなったので自分なりの考えをまとめることにした。 ファーストパーティのアプリが使うWeb API（プライベートなWeb API）の場合はセッションを使うケースもあるだろうが、セッションを使うケースでは悩むことも少なかったので、ここではアクセストークンを用いた認可にフォーカスして考えてみたい。ケースとしてはユーザー毎にアクセストークンが発行され、Browser-BasedアプリやNativeアプリからWeb APIが叩かれることを想定している。 追記 2019/03/04 認証や認可周りについてよく拝見させてもらっている方にブログで言及していただきました。合わせて読むことをお勧めします。 ritou.hatenablog.com
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
OpenID 2.0 Shutdown Timetable | OpenID 2.0 (Migration) - Google Accounts Authentication and Authorization — Google Developers
Send feedback OpenID Connect Stay organized with collections Save and categorize content based on your preferences. Google's OAuth 2.0 APIs can be used for both authentication and authorization. This document describes our OAuth 2.0 implementation for authentication, which conforms to the OpenID Connect specification, and is OpenID Certified. The documentation found in Using OAuth 2.0 to Access Go
事務局ブログ：「Covert Redirect」についての John Bradley 氏の解説（追記あり）
追記 (5/7 20:30): 本文中に「まともなブラウザーであれば、そのフラグメントを URI の一部にするようなことはないから、オープン・リダイレクターには送られない。」とありますが、少なくとも Chrome と Firefox はリダイレクト時に URI フラグメントをそのまま保つ (i.e. 不十分な redirect_uri チェック & オープン・リダイレクター & インプリシット・フローの場合、アクセス・トークン入りの URI フラグメントを、ブラウザーがそのままリダイレクト先へのリクエストに用いる) とのことです。続報があり次第追記します。 追記2 (5/7 23:50): John Bradley 氏自身によるフォローアップを訳しました。 Covert Redirect and its real impact on OAuth and OpenID Connect を、と
WebMockでスタブしつつSSLのOpenID認証を使う - There's an echo in my head
結論からいうと WebMockでHTTP通信をスタブしつつとSSLのOpenID認証を使う場合には次のようにWebMockを設定する必要がある: WebMock.allow_net_connect!(net_http_connect_on_start: true) どういうことかというと ruby-openidはidentifierがSSL（https://から始まる）の場合に、事前に通信できるかどうかをチェックしてる。実装としてはこのあたり。 そしてそれはNet::HTTP#startでNet::HTTP#connectが呼ばれていることを前提としている。もし呼ばれていない場合には@socketがセットされていないので、次のようなエラーが出る: OpenID::DiscoveryFailure: Failed to fetch identity URL https://xxxxxx/ :
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
OpenID Connect Core draft 01の内容をななめ読み - r-weblife
[Openid-specs-ab] Connect-core and Connect-AB OpenID Connect/AB周りの仕様について、さっぱりMLに貢献できておりませんが、少しでも近況を多くの人に広めて良いものができる手伝いができればと思っています。 今回は、"OpenID Connect Core 1.0 draft 01"です。 名前の通り、Coreということで用語やフロー、やりとりされる内容が定義されています。 Terminology OAuth 2.0の用語に加えて、OpenID関連の以下の用語が加えられています。 OpenID Provider (OP) : OpenID ConnectのメッセージをサポートするAuthZ Server Relying Party (RP) : Client と Resource Servers(?) OP Endpoints : A
ちょっと前に話題になったOpenID Connectの仕様とは？ - r-weblife
OpenID Connectでググってみたものの、紹介記事ばかりで中身を説明してる人があんまりいないようでした。 仕様ドキュメント？かどうかわかりませんが、まともなドキュメントは http://openidconnect.com/ しかありません。 英語読めるエンジニアならこれ読んでだいたいわかってるのかもしれませんが、ざっとまとめておきます。 3行で説明 OAuth 2.0を使って、URL形式のUser Identifierを返す User Identifierは User Info APIとして属性情報取得に利用できる host-metaを利用した独自Discoveryと、DynamicにClient登録のしくみがある 処理フロー OpenID Connect on Web Server Profile シーケンスはこんな感じですね。 ここでは、一番処理の多いケースを考えます。 条件は
「番号」制度の情報連携基盤は複雑か？
国民ID制度、「番号」制度（あやまって、共通番号制度とも呼ばれることがあるが）のコンテキストで語られるシステム基盤に、「情報連携基盤」とよばれるものがあります。下の図（内閣官房情報連携基盤技術ワーキンググループ中間報告より）のオレンジの箱がそれです。 （図1）番号制度における符号連携のイメージ どうもここの部分が、各界の「識者」の方々には、「複雑怪奇」「動かない」とか「ベンダーを利するだけ」などと何かと評判が悪いようです。 実際には、このような仕組みを入れることは、プライバシーやセキュリティの観点から不可欠で、これの理由も延々と報告書やら議事録やらに収録されているのですが、私の観点としては、（やり方に気をつけさえすれば）そもそも「複雑」ですらないので、まずそのことについて書きたいと思います。 インターネットって複雑怪奇で動かないシステム？ そこで、質問。 今、この記事をご覧になっているあな
中小企業では、社員のアカウント管理がGoogleやセールスフォースなどクラウドに移行していくのではないか
中小企業では、社員のアカウント管理がGoogleやセールスフォースなどクラウドに移行していくのではないか 「社員のアカウントを社内システムで管理するのは大企業だけになって、中小企業ではセールスフォース・ドットコムやGoogle Appsなどクラウドに移行していくのではないか」。8月5日に開催されたイベント「OpenID TechNight #7」で、企業のアカウント管理に関する予想を語ったのは工藤達雄氏。7月に米国で行われた「Cloud Identity Summit 2011」の報告の中でのことでした。 一般に多くの企業は社員のアカウントを社内で管理しています。社内のディレクトリサーバで社員情報を管理し、それを元にシングルサインオンの仕組みを用いて業務アプリケーションやメール、グループウェア、ファイル共有などへログインできるシステムを構築している企業もあるでしょう。 しかしこうした規模の
認証と認可の違い
OpenIDを解説する際にしばしば登場する「認証」「認可」の言葉はそれぞれどういった意味で利用しているのでしょうか。両者は明確に区別しなければならないものなのでしょうか。また、OpenID Authenticationについても教えてください。 「認証」「認可」は、OpenID以外でもセキュリティ関連のトピックではしばしば登場する単語です。いったん理解してしまえばさほど難しいものでもありませんが、多くの人が混同されているようですのでこの機会にしっかり覚えてしまいましょう。認証・認可は英語では以下のような単語になります。 認証（Authentication） 認可（Authorization） 認証（Authentication）とは 関連記事 実は簡単なOpenIDの認証手続き OpenIDにかんするさまざまな疑問を解消していく本連載。今回は、OpenIDではどのような流れで認証手続きが行
非技術者のためのOAuth認証(?)とOpenIDの違い入門【2023年版】
昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 Youtube版 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」（ユーザ認証）という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をして
OpenIDでGoogleからグローバルユニークなユーザー識別子を取得できるかもしれない方法 - r-weblife
「GoogleのOpenIDってrealm単位で変わるんですよねー。」 「いわゆるPPIDですよね。他のサイトと識別子変えてくれるので名寄せできないんですよ。」 「ドメイン変わったときにユーザー引き継ぎたいときはどうすれば？Gmail(メアド)でむりやりつなぐしかない？」 この話は前からありましたが、最近Janrain Engage (formerly RPX)を久々に使ったら、GoogleのユニークなIdentifierっぽいのが取れました。 そのOpenID AuthNリクエストからその取得方法を調べました。 ※Janrain EngageってのはシンプルなAPIで簡単にOpenIDのRPやtwitter/facebookのOAuth Cnsumer/Clientになれちゃうサービス？プロダクト？です。 Janrain Engageの仕様などについてはここでは触れません。 振り返り；O
はてなブログ | 無料ブログを作成しよう
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://leandrob.com/2014/05/covert-redirect-facebook-and-espn-security-oh-my-god/
http://www.machu.jp/posts/20110722/p01/
docomo IDについて サイト運営者様向け | NTTドコモ
TechCrunch | Startup and Technology News
はてなブログ | 無料ブログを作成しよう
TechCrunch