社内向け勉強会で発表した内容です。 30分でと書いてありますが、実際には50分かかりました。 また時間の関係で結構省いたりしている箇所があります。 2020/07/19追記 ご指摘をいただいた箇所を多々修正いたしました。 特にOIDCとSPAの章が初版とは大幅に変更されていますのでご注意く…
OAuth 2.0に対応したAPIクライアントのアプリを書きたい気持ちになったのですが、テストをどうするか考えながらOSSの認可サーバーをローカルに立てたりするかなど考えていたら、OAuth 2.0 Playgroundというものを知りました。 こちらは実際に認可サーバーを使ってOAuth 2.0 のクライアントの気持ちになれるチュートリアルで、良さそうだったので紹介します。 OAuth 2.0 Playground okta社によって提供されている、OAuth 2.0 とOIDCのフローを、実際に体験するためのチュートリアルです。 Authorization Code PKCE Implicit Device Code OpenID Connect に対応しており、実際に認可サーバーを叩きながらインタラクティブに学ぶことができます。 やってみる 今回はAuthorization Code
最近Web APIの認可について思いを馳せる機会があったのだけど、どの方法で認可を実装するのがスタンダードなのか、そもそもそんなものは最初からないのか、よく分からなくなったので自分なりの考えをまとめることにした。 ファーストパーティのアプリが使うWeb API(プライベートなWeb API)の場合はセッションを使うケースもあるだろうが、セッションを使うケースでは悩むことも少なかったので、ここではアクセストークンを用いた認可にフォーカスして考えてみたい。ケースとしてはユーザー毎にアクセストークンが発行され、Browser-BasedアプリやNativeアプリからWeb APIが叩かれることを想定している。 追記 2019/03/04 認証や認可周りについてよく拝見させてもらっている方にブログで言及していただきました。合わせて読むことをお勧めします。 ritou.hatenablog.com
プライベートの勉強は気が向くままにふらふらと。梅田の地下街を歩いてる感じで!(←つまり迷ってる) 元々は、Pivotal Japanさんの、この「今日から君もヒーローだ!」的なタイトルに惹かれてJava(Spring Cloud)でマイクロサービス作るぞーって進めてみたのであった。が、早速その2の「認可サーバーを立ち上げよう!」で「あー、これ知らない。分かんない。もう寝たい。」となってしまったのだった。 そんな僕が「なんとなく分かった!」になるまでの物語。・・・になるはず(ここを書いてる今はまだ分かってない)。 たぶん1ヶ月したら何を読んだか忘れてると思うので記録しとくことにした。 github.com ゴール OAuth 2.0って聞いたことあるけど、よく知らない。この辺、マイクロサービスの認証・認可部分で必要そうだなーって思うので、OpenID 2.0とOpenID Connectも含
最近の僕の趣味は、stack overflowに来た質問に回答を付ける、ということです。特に本家英語版の方では、英語の読み取りと作文の練習をかねてやってます。もちろん、日本語版の方でも、回答できそうな質問が来たら、積極的に回答するようにしています。たまに間違えた回答付けてしまって-1をもらうこともありますが、それを含めての貢献かな、と。気にしない気にしない。 さて、日本語版の方でOAuthに関する以下の質問が来ていました。 OAuthはどのようにしてソーシャルログインとして使用されるようになったのでしょうか? 下記の記事をみるとOAuthはもともと外部からAPIを呼ぶためのものであり、ソーシャルログインとして使うのはHack的な使い方のような印象をうけました。 本来の目的が、ソーシャルログインのためでないならどのような経緯(どこどこのサービスで使われたのがきっかけというような歴史)でソーシ
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita ってのになんかフォローアップしろよ的なのが来たので。 ざっと読んだ感想としては、「OpenID Connect の OPTIONAL な機能全部実装したら、そら大変ですね」という感じ。(Authlete に関しては、OpenAM みたいな感じで使われる、OpenAM よりはるかに簡単に使える代わりに有料の何かなんだろうな、というイメージです) OAuth は必要なのか? Basic 認証は死んだ。 ユーザー単位での API のアクセスコントロールがしたいです。 っていう前提で話すると、OAuth 以外まともな選択肢が無いんじゃないでしょうか。 OAuth の各種 Extension (RFC 6749 & 6750 以外にいろいろある) に関しては、適宜必要なのを実装すればいいんだけど
Abstract OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである. サードパーティーアプリケーションによるアクセス権の取得には, リソースオーナーとHTTPサービスの間で同意のためのインタラクションを伴う場合もあるが, サードパーティーアプリケーション自身が自らの権限においてアクセスを許可する場合もある. 本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It re
昨年末にOpenIDファウンデーション・ジャパン参加企業の有志数名で翻訳・教育 Working Groupというのを立ち上げて、現在は主にドキュメントの翻訳を行っています。 現在4本のドキュメントの日本語版を翻訳・教育 Working Group のサイトで公開しています。(この記事の末尾にリンクあり) 翻訳後のドキュメント以外に、githubレポジトリも公開しています。forkもpull requestも大歓迎!原文との比較がしやすいように、各翻訳版のXMLファイルにはコメントアウトの形で原文も残されています。 翻訳版ドキュメントへのコメント・質問は翻訳・教育 Working Group のサイトのコメント欄にどうぞ。 OpenID Authentication 2.0 OpenID Attribute Exchange 1.0 OpenID Simple Registration Ex
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く