OAuth 2.0 の Response Type 全パターン - OAuth.jp
特に新しい話題ではないですが、定期的に質問されてる気がするので記事にしときます。 OAuth 2.0 の Core には、”code” と “token” という2つの response_type が定義されています。 それぞれ “Code Grant” と “Implicit Grant” と呼ばれることもありますし、歴史的経緯により “Code Flow” と “Implicit Flow” と呼ぶこともあります。 ほとんどのケースでは、この2つの response_type のどちらかを使っているかと思いますが、実はこれ以外にも以下の response_type のパターンが存在します。 (仕様はこちら) none code token id_token id_token code id_token token id_token code token id_token ってのが含まれ
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 は、アクセストークンを発行
RFCとなった「OAuth 2.0」――その要点は？
RFCとなった「OAuth 2.0」――その要点は？：デジタル・アイデンティティ技術最新動向（2）（1/2 ページ） いまWebの世界では、さまざまなWebサービスが提供するプラットフォームと、サー ドパーティが提供するアプリケーションがAPIを中心に結び付き、一種の「APIエコノミー」を形成しています。この連載では、そこで重要な役割を果たす「デジタル・アイデンティティ」について理解を深めていきます。 再び、デジタル・アイデンティティの世界へようこそ 前回「『OAuth』の基本動作を知る」ではOAuthの仕様がどういうものかについて説明しました。今回は引き続き、 OAuth 1.0とOAuth 2.0の違い OAuth 2.0をセキュアに使うために知っておくべきこと について述べていきます。 OAuth 1.0とOAuth 2.0の違い クライアントタイプの定義 OAuth 2.0では、O
Bearer Token とは？
► 2024 (23) ► 1月 (23) ► 2023 (2) ► 12月 (1) ► 6月 (1) ► 2022 (6) ► 12月 (1) ► 11月 (2) ► 10月 (1) ► 7月 (1) ► 2月 (1) ► 2021 (11) ► 12月 (2) ► 8月 (1) ► 7月 (2) ► 5月 (1) ► 4月 (2) ► 3月 (1) ► 1月 (2) ► 2020 (10) ► 12月 (1) ► 10月 (1) ► 9月 (2) ► 7月 (1) ► 6月 (1) ► 5月 (3) ► 4月 (1) ► 2019 (24) ► 12月 (1) ► 11月 (2) ► 10月 (1) ► 9月 (2) ► 8月 (1) ► 7月 (1) ► 6月 (7) ► 5月 (2) ► 4月 (2) ► 3月 (2) ► 2月 (2) ► 1月 (1) ► 2018 (35) ►
OAuth 2.0 — OAuth
OAuth 2.0 OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group. OAuth 2.1 is an in-progress effort to consolidate OAut
非技術者のためのOAuth認証(?)とOpenIDの違い入門【2023年版】
昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 Youtube版 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」（ユーザ認証）という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をして
Spring Security OAuth
Deprecation Notice The Spring Security OAuth project is deprecated. The latest OAuth 2.0 support is provided by Spring Security. See the OAuth 2.0 Migration Guide for further details. OAuth 2 Developers Guide Introduction This is the user guide for the support for OAuth 2.0. For OAuth 1.0, everything is different, so see its user guide. This user guide is divided into two parts, the first for the
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
モバイルアプリのユーザ認証方法についてまとめてみた - Qiita
追記 (2018-10-08) 4年以上前に書いた記事ですが、Access Token として JWT を利用することは非推奨なようなので、お詫びして修正致します。 参考: どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ 概要 みんなやってるはずなんだけど、あまりまとまった情報がなかったので書いてみます。認証周りはセキュリティを気にして、みんな書きたがらないのかな？それとも私の調べ方が悪かっただけ？マサカリお待ちしてます。 認証の基本方針 +--------+ +--------+ | | | | | |----(1) Credential ------------>| | | | | | | |<---(2) Access Token -----------| | | | | | | Client | | Server | | | | | | |----(3)
OpenID Foundation Japan - 翻訳・教育 Working Group
OpenID Foundation Japan 翻訳・教育 Working Group は、OpenID Foundation Japan 参加メンバーを中心に、有志により運営されています。現在は主に OpenID & OAuth 関連仕様書の翻訳活動を行っています。 翻訳ドキュメント一覧 OpenID 認証は、エンドユーザが識別子 (Identifier) を管理していることを証明する方法を提供するものである。OpenID 認証を利用すれば、リライングパーティー (Relying Party、以下 RP) はエンドユーザのパスワードやメールアドレスなどにアクセスする必要がなくなる。 OpenID Attribute Exchange は、エンドポイント間で属性情報を交換するための OpenID の拡張仕様である。ユーザーの属性情報を更新または取得するためのメッセージを提供する。 Open
JSON Web Token (JWT) - OAuth.jp
@novです。 個人的に最近OAuth 2.0よりJWT (というかJWS) を利用するシーンが多く、毎回同じ説明するのもめんどくさいのでブログにまとめるかと思い、どうせならOAuth.jpに書くかということで、こんな記事を書いております。 （そろそろJWTとJWSは、OpenID Foundation Japanの翻訳WGで翻訳するべき？） JSON Web Token (JWT) とは、JSONをトークン化する仕組み。 元々はJSONデータにSignatureをつけたりEncryptionする仕組みとして考えられたものの、Signature部分がJSON Web Signatue (JWS)、Encryption部分がJSON Web Encryption (JWE) という仕様に分割された。 それぞれ2012年10月26日現在の最新仕様はこちら。 （JWTとJWSは既にだいぶ仕様が固
アクセストークンに有効期限を設けるべきかどうか - Qiita
OAuthプロバイダを提供することになったとして、アクセストークンに有効期限を設けるべきかどうかについて考えたい。OAuth 2.0の仕様にはアクセストークンの期限切れに関係する仕様が定義されているし、セキュリティをより強固にするためにアクセストークンは一定期間で期限切れにするべきだという主張があったと思う (確認していないので無いかもしれない)。しかしながら、例えばGitHub API v3ではアクセストークンに有効期限を設けていない。この投稿では、アクセストークンの有効期限に関係して起こり得る問題を取り上げる。 アクセストークンに有効期限を持たせておくとちょっと安全 アクセストークンが悪意のある第三者に漏洩してしまった場合、そのアクセストークンに認可されているあらゆる操作が実行可能になってしまうという問題がまず存在する。ここでもしアクセストークンに有効期限が存在していたとすれば、その操
iPhone(iOS)でfourSquareの認証、API通信をお手軽にやっちゃう。
iPhoneでのfoursquareの認証が、思った以上にサクッとできちゃったのでメモします。 今回やったのは、foursquareのOauth認証とAPIから自分の情報を取得すること。 Oauth認証は、以下のURLの真似をすれば問題なく認証されます。 https://github.com/anoopr/core-data-talk/blob/master/example/Classes/FoursquareAuthViewController.m なかにある、 CLIENT_ID CALLBACK_URL これらは、foursquareのdeveloperページで登録します。 コードを書く前にこっちを登録したほうがいいでしょう。 登録時「コールバックURLってなんじゃ？」って思ったんですけど、どうやらアクセストークンをつけて返してくれるURLみたいです。まあなんでもいいみたいです。ただ
OAuthでつぶやく その2 oauthconsumerを使う - Still Life
もう５ヶ月も前になってしまいましたが、以前iPhoneアプリでTwitter連携するためのライブラリについて紹介しました。（OAuthでつぶやく） https://github.com/jdg/oauthconsumer こちらでダウンロードしたライブラリの取り込みかたについて記事にしたのですが、Twitterと連携できた喜びのあまり勢いだけで記事にしてしまった状態でした。 時間が空いてしまいましたが、フォロー記事を書いてみたいと思います。 結論からいいますと、前回記事に書いた内容の手順はいっさい行わなくても動作しました。 OAuth認証の段階として、oauth_verifierというユーザー情報のひとつを使用するのですが、前回の記事執筆時はまだライブラリに実装されていませんでした。でも最新のライブラリではちゃんと追加されています。ライブラリを持ってくれば、何も難しい手順なくTwitter
Objective-CでTwitter APIを使う 色々 - すぎゃーんメモ
Twitter APIの認証 Twitter APIの使用は、現在"BASIC認証"と"OAuth"の2通りの方法が用意されている。が、今年6月(？)でBASIC認証が使えなくなるという噂で、今後はAPIを使用するのにはOAuthを使用する必要が出てくるようだ。 まぁBasic認証はパスワードだだ漏れになっちゃうからやめておこうよ、という話ですかね。 Basic認証 - Wikipedia Code — OAuth iPhoneアプリでTwitter APIを使いたい場合 結構iPhoneのTwitterクライアントアプリってたくさんあるけど、どういう実装なのだろう？ 大抵は初回起動時に設定画面でユーザー名とパスワードを入力させて、それを使ってBASIC認証でアクセスしているのではないのかな？ BASIC認証を使うAPIアクセスの実装は比較的簡単。(base64エンコーディングを実装せずに
認証認可手順（新方式） - mixi Connect
各種APIをクライアントプログラムから利用するためには、OAuth 2.0 Protocolにより規定された認可を行うことが求められます。この手順により、クライアントプログラムがどのようなAPIアクセスを行い、そしてどのような情報が参照または更新されるのか（これをスコープと呼びます）がユーザに提示されます。ユーザの認証、および提示されたスコープについてユーザが同意した場合にのみ、クライアントプログラムはAPIにアクセスするための情報（トークンなど）を得ることができます。 [RFC 6749 - The OAuth 2.0 Authorization Framework] http://tools.ietf.org/html/rfc6749 [RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage] http:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Authorization Code Flow for Server-side Apps - Yahoo Developer Network
OAuth Security
How is OAuth 2 different from OAuth 1?
Authorization Codeフロー - Yahoo!デベロッパーネットワーク
