OpenID や OAuth の役割と、既存のシングル・サインオンとの違い：Goodpic
OpenIDやOAuthと、LDAPやSAMLなどのシングル・サインオン（Single Sign On）は似ているようで違う。その違いをちゃんと理解できていないので、勉強モードで調べた情報をまとめてみた。かなり長くなってしまったので、まずはまとめから。 既存のシングル・サインオンは、本人性とシステム間の相互信頼がベース そもそものニーズと、歴史的経緯から以下のような方面に強い。 イントラネットの個人電話帳から、ディレクトリーサービスに進化した ディレクトリーサービスの個人の役割に応じて、アクセス権限が与えられた 社内のディレクトリ、サービス間で認証モジュールを共有することで、シングル・サインオンを実現 イントラネットからインターネットに利用範囲を拡大 OpenIDやOAuthは、ウェブによるウェブのための仕組み 既存の認証システムやシングル・サインオンの延長ではなく、ウェブサイトに特化した
マイクロサービスで必要になるかなぁって思って僕がOAuth2とOpenID Connectをなんとなく分かるようになるまでの物語 - Mitsuyuki.Shiiba
プライベートの勉強は気が向くままにふらふらと。梅田の地下街を歩いてる感じで！（←つまり迷ってる） 元々は、Pivotal Japanさんの、この「今日から君もヒーローだ！」的なタイトルに惹かれてJava(Spring Cloud)でマイクロサービス作るぞーって進めてみたのであった。が、早速その2の「認可サーバーを立ち上げよう！」で「あー、これ知らない。分かんない。もう寝たい。」となってしまったのだった。 そんな僕が「なんとなく分かった！」になるまでの物語。・・・になるはず（ここを書いてる今はまだ分かってない）。 たぶん1ヶ月したら何を読んだか忘れてると思うので記録しとくことにした。 github.com ゴール OAuth 2.0って聞いたことあるけど、よく知らない。この辺、マイクロサービスの認証・認可部分で必要そうだなーって思うので、OpenID 2.0とOpenID Connectも含
OpenID や OAuth の役割と、既存のシングル・サインオンとの違い：Goodpic
This shop will be powered by Are you the store owner? Log in here
Facebook Connect, OAuth and OpenID: The differences and the future
The <3 of EU tech The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now! OpenID is an old standard. In fact, it hasn’t even been updated since 2007. In its path, however, it has picked up some great sites. For that matter, even Facebook allows you to sign in and use its site via OpenID a
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
[参考情報] 【永久保存版】OAuth 2.0 / OpenID Connect シーケンスまとめ URL：https://qiita.com/kura_lab/items/812a62b5aa3427bdb49d タイトル： 『OpenID Connect 入門 〜コンシューマー領域におけるID連携のトレンド〜』 概要： コンシューマー領域におけるID連携のトレンドであるOpenID Connectの概要と仕様のポイントについてご紹介します。 OpenID TechNight Vol.13 - ID連携入門 Aug. 26, 2015 URL：https://openid.doorkeeper.jp/events/29487
OAuthとは何か?
OAuth(1.0)については、ゼロから学ぶOAuthとかAPIアクセス権を委譲するプロトコル、OAuthを知るあたりで色々と説明されているけど、忘れた時にふと読み返すには少し記事が長いと思う。 今回は、ざっくりとOAuthとは何か、その承認プロセスはどんな感じかを自分なりに短くまとめてみる。 何をするためのものか例えば、自分のGoogleカレンダーを見やすく表示してくれるアプリケーションがあったとする。これを利用するには、アプリケーションの入手の他に、Googleカレンダーデータの取得が必要になる。 Googleカレンダーデータの取得を実現する一番簡単な方法は、アプリケーションにGoogleのIDとパスワードを設定すること。でも、IDとパスワードをアプリケーションに設定するのがちょっとイヤな場合がある。Webアプリケーションなどがそれ。 そんな時、OAuthを使うとGoogleのIDとパ
OAuthの鍵がたくさん登場するが各々の役割についてまとめてみた - mabots' blog
OAuthには鍵がいっぱい登場します。この鍵についての理解を深めるため社内勉強会の講義の内容を一部まとめて公開しておきます。 登場するアクターの解説 特に解説不要かもしれませんが、念のため。 Consumer ServiceProviderに依存してアプリケーションを提供する主体 メリット Service Providerの会員基盤を利用できる 自前のアカウント管理機構を用意しなくてよい Service ProviderのID、パスワードをConsumerのDB等に可逆形式で保存する必要がない User 実際にアプリケーションを利用するユーザー メリット 最初にアクセスするのはConsumerの画面 ID/PASSを渡さなくて良い 会員登録も比較的しなくてよい。簡単。 Consumerへ利用許可を与えてもあとからServiceProviderかに拒否できる ServiceProvider
APIアクセス権を委譲するプロトコル、OAuthを知る ― ＠IT
クロスドメインでのデジタルアイデンティティを守る APIアクセス権を委譲するプロトコル、 OAuthを知る 作島 立樹 NRIパシフィック 2008/1/21 マッシュアップと呼ばれる仕組みで、既存のWebサービスが次々とつながり、新たなサービスが登場している。しかし、メールアドレスなど重要な個人情報が意図せずに「つながれてしまう」可能性もある。そこで登場したのがアクセス権の「委譲」を目的としたプロトコル、OAuthである。本記事ではOAuthの仕組みとともに、なぜそれが登場したのかという背景にも触れる（編集部） マッシュアップの犠牲になるユーザーのアイデンティティ GETなどのHTTPメソッドをもちいてURLへリクエストする、いわゆる「RESTful」【注1】なWeb APIを使ったアプリケーション同士の交流は、いままさに隆盛を極めている。「マッシュアップ」と呼ばれているこのサービス形態
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Inactive or retired community