公開資料 OpenIDファウンデーション・ジャパンでは、OpenID関連技術仕様の日本語訳や、プレゼンテーション資料、その他各種文書を公開しています。 技術仕様 OpenID Connect OpenID Connectは、OAuth 2.0をベースとする、シンプルなアイデンティティ連携プロトコルです。 ここでは日本語訳された仕様を紹介しています。原文ならびにその他の仕様については http://openid.net/connect/ をご参照ください。 OpenID Connect 1.0 specification OpenID Connect Core 1.0 日本語訳 OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである. このプロトコルは Client が Authorization Server
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、ID連携黒帯 倉林 雅（@kura_lab）です。 昨年の「知っておきたい7つのID連携実装パターン」に続き今年も23日を担当することになりました！祝日も記事を投稿いたします！ 今年のAdventCalendarも「Yahoo! JAPANを支える技術」をテーマとしていますが、今回は少し先の未来をみすえて今後Yahoo! JAPANを支えることになるかもしれない新しい技術についてご紹介しようと思います。 すでにPCやスマホ上で認証を行いサービスを利用することは普通になりつつありますが、今後はテレビやゲーム機、ビデオカメラなどのデバイスでも認証や決済を利用したサービスが増えてくると思われます。Identity Provi
OAuthプロバイダを提供することになったとして、アクセストークンに有効期限を設けるべきかどうかについて考えたい。OAuth 2.0の仕様にはアクセストークンの期限切れに関係する仕様が定義されているし、セキュリティをより強固にするためにアクセストークンは一定期間で期限切れにするべきだという主張があったと思う (確認していないので無いかもしれない)。しかしながら、例えばGitHub API v3ではアクセストークンに有効期限を設けていない。この投稿では、アクセストークンの有効期限に関係して起こり得る問題を取り上げる。 アクセストークンに有効期限を持たせておくとちょっと安全 アクセストークンが悪意のある第三者に漏洩してしまった場合、そのアクセストークンに認可されているあらゆる操作が実行可能になってしまうという問題がまず存在する。ここでもしアクセストークンに有効期限が存在していたとすれば、その操
追記 (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 を、と
tl;dr Covert Redirect Vulnerability is a real, if not new, threat when combined with Implicit Grant Flow (not Code flow) This Covert Redirect Vulnerability in OAuth 2 is an interesting one. There’s a couple of defending arguments that this isn’t a flaw in OAuth itself. While I agree that it isn’t a flaw in the protocol, I think the threat is a real one, combined with a) a loose validation on redir
TwitterのOAuth脆弱性 Presentation Transcript TwitterのOAuth脆弱性 2013-03-01 Xtone Ltd. ピザ会 Aki / @nekoruri なにがおきたの？( ^o^) なんか友達からURL送られてきたお なにがおきたの？( ˘⊖˘) 。o(ID/Pass入力しなきゃ安全だよな……) なにがおきたの？|URL| ┗(☋｀ )┓三 なにがおきたの？( ◠‿◠ )☛ アクセストークンは頂いた、抵抗は無意味だ なにがおきたの？▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわあああああああ なにがおきたの？( ^o^)なんか友達からURL送られてきたお( ˘⊖˘) 。O(ID/Pass入力しなきゃ安全だよな……)|URL| ┗(☋｀ )┓三( ◠‿◠ )☛アクセストークンは頂いた、抵抗は無意味だ▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわああああ
おはようございます、ritouです。 今回は、一部で先週話題なりましたOAuth 2.0のImplicit Flowについてのエントリになります。 (2012/2/7 いろいろと修正しました。) 単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる | @_Nat Zone Thread Safe: The problem with OAuth for Authentication. 今回は以下の内容について整理したいと思います。 OAuth 2.0のどの機能にセキュリティホールがあるのか 誰が攻撃者になれるのか 対策 OAuth 2.0 Implicit Flowとは OAuth 2.0ではサードパーティーアプリケーションが保護リソースへのアクセス権限を得るためのいくつかのフローが定義されています。 (仕様中ではFlowやGrant Type
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
Java で文字列を扱うのはあまり慣れておらず、文字列をパーセントエンコードするのにちょっとてこずったので軽くメモを。 文字列 (String オブジェクト) とバイナリ列 (byte 型配列) の相互変換 Java において、文字列を任意のエンコーディングでエンコードしてバイナリ列を得るには、String#getBytes( Charset ) メソッド を使用します。 // "あいうえお" という文字列が UTF-8 エンコードされたバイナリ列 byte[] encodedStr = "あいうえお".getBytes( Charset.forName( "UTF-8" ) ); また、バイナリ列 (byte 型配列) を文字列に戻す場合には、String クラスのコンストラクタ String( byte[], Charset ) を使用します。 String str = new Str
サンプルソースはまとめてgithubにあります http://github.com/tototoshi/OAuthSample とりあえず、request tokenを取得するJavaプログラム https://github.com/tototoshi/OAuthSample/blob/master/java/src/main/java/com/github/tototoshi/oauth/twitter/RequestToken.java https://github.com/tototoshi/OAuthSample/blob/master/java/src/main/java/com/github/tototoshi/oauth/twitter/OAuthUtil.java RequestToken.javaの説明 getRequestParameter() private Stri
ネイティブアプリで実践！ mixi Graph API活用法 OAuth 2.0を使う ソーシャルなAndroidアプリの作り方 株式会社ミクシィ システム本部 技術部 たんぽぽグループ 藤崎 友樹 プラットフォームサービス開発部 鶴原 翔夢 2011/3/30 「OAuth」を使ってスマートでソーシャルなアプリを作ろう 最近よく耳にする「OAuth」とは、mixi、Facebook、Twitterなどの外部サービスと自アプリケーションを連携するための技術です。 「クラウド」「ソーシャル」というキーワードが叫ばれている昨今では、こういった連携をいかにうまく行うかということがユーザー体験を向上させる鍵となります。 特に「ソーシャル」を取り入れることは以下のような点でメリットがあると考えられます。 ユーザーのソーシャルグラフを活用して、アプリをバイラル・マーケティングできる 現実の人間関係をベ
昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」（ユーザ認証）という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をしているサイトである伊
Loading… Flash Player 9 (or above) is needed to view presentations. We have detected that you do not have it on your computer. To install it, go here. OAuth,xAuthとOpenIDについて - Presentation Transcript OAuth/xAuthとOpenID について第１２回 OSS勉強会 2011/1/12 @kidooom 認証と認可の違い● 認証（Authentication） ● そのユーザーが自分の物であると主張するIDに対し て、そのIDが確かにそのユーザーの物であるということ を保証すること● 認可（Authorize） ● 認証されたIDを受け入れ、サービスに対して適切な権 限を与えること Open
OAuth 2.0で Webサービスの利用方法はどう変わるか ソーシャルAPI活用に必須の“OAuth”の基礎知識 株式会社ビーコンIT 木村篤彦 2011/2/2 OAuthの現状と1.0の問題点、2.0での特徴などを解説し、2.0の例としてFacebookのAPIの利用例を紹介します OAuthの現状 TwitterがOAuth 1.0を採用したのを皮切りに、今では多くのサービスがOAuth 1.0に対応しています。国内でも、例えば、マイクロブログ型コラボツール「youRoom」、小規模グループ向けグループウェア「サイボウズLive」、「はてな」のいくつかのサービス、「Yahoo!オークション」、リアルタイムドローツール「Cacoo」などがOAuth 1.0に対応したAPIを公開しています。 ここ数年でOAuthはさまざまなWebサービスのリソースを利用する際の認証方式として普及してき
OAuth 2.0のDraft 13出ました。 draft-ietf-oauth-v2-13 - The OAuth 2.0 Authorization Framework Facebookやmixi Graph APIなどを使って開発されたことがある方は、OAuth 2.0 Draft 10の仕様はほぼ理解されていると思います。 Draft 10は単体である程度まとまった仕様として書かれていましたが、そのあとのDraft 11から構成の見直しなどが行われました。 もうそろそろ決まりそうだという噂があるので、今一度ざっくり最初からまとめ直していきます。 ただ、ClientやAuthorization Serverなど、基本的な説明は省略しています。 Draft 11以降に出てきた(と思われる)説明などを簡単にまとめたつもりです。 毎度のことながら、長いうえにこれは翻訳ではないので、厳密に調
The OAuth 2.0 Protocol draft-ietf-oauth-v2-10 Abstract これはOAuth 2.0プロトコルの仕様書である. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is
クロスドメインでのデジタルアイデンティティを守る APIアクセス権を委譲するプロトコル、 OAuthを知る 作島 立樹 NRIパシフィック 2008/1/21 マッシュアップと呼ばれる仕組みで、既存のWebサービスが次々とつながり、新たなサービスが登場している。しかし、メールアドレスなど重要な個人情報が意図せずに「つながれてしまう」可能性もある。そこで登場したのがアクセス権の「委譲」を目的としたプロトコル、OAuthである。本記事ではOAuthの仕組みとともに、なぜそれが登場したのかという背景にも触れる（編集部） マッシュアップの犠牲になるユーザーのアイデンティティ GETなどのHTTPメソッドをもちいてURLへリクエストする、いわゆる「RESTful」【注1】なWeb APIを使ったアプリケーション同士の交流は、いままさに隆盛を極めている。「マッシュアップ」と呼ばれているこのサービス形態
The OAuth 1.0 Protocol draft-hammer-oauth-10 Abstract OAuth は、リソースオーナー (別のクライアントやエンドユーザー) に代わって、サーバーリソースにアクセスするための方法を、クライアントに提供するものである。また、リダイレクトを利用することで、エンドユーザーはクライアントにユーザ名やパスワードを共有することなく、サーバーリソースへの第三者アクセスを認可することができる。 Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering T
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
