SPA+Backend構成なWebアプリへのOIDC適用パターン - r-weblife
ritouです。 マシュマロでSPA+BE構成のWebアプリでOAuthやOIDCしたい！って話をよくいただきます。 最近だと、こんな質問がありました。 OIDCから発行されたトークンの取り扱いについて質問させてください。 SPA +OIDC(認可コードフロー)構成によるWEBアプリケーションの開発を考えています。 idPによる認証後、バックエンドとフロントエンドのAPI通信に使うべきはIDトークンとアクセストークンだとどちらになるのでしょうか？ 個人的には「ログイン成功した時点でOIDCの処理は終わり、あとかSPA + BEが独自のセッションCookieなりトークンを用いてよろしくやったら良いよ」という設計を適用します。もはや質... 続き→https://t.co/O2KWJrL4Mi#マシュマロを投げ合おう— 👹秋田の猫🐱 (@ritou) 2024年10月20日 SPAだろうが
"OpenID Connectは認可のための仕組みであるOAuth 2.0を認証のために拡張したもの" という表現が気になったが実は... - r-weblife
ritouです。 あることがきっかけで、これが気になりました。 10年間で熟成されてしまった感のある「OIDCはOAuth 2.0を"認証もできる(認証用途に利用できる)ように"拡張した」っていう表現だが、プロトコルの解説にあたってもその流れでやられるとモヤるところがあるのでなんとかしておくべきだったのかもしれない。— 👹秋田の猫🐱 (@ritou) 2024年2月1日 この表現、検索するとたくさん出てくるんです。 仕様策定の時期 OIDC Core 1.0にある "OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol." という記述の解釈 というあたりからこのような表現になっているのでしょう。 ただ、この前提でプロトコル自体を解説、理解しようとすると何かうまくいかないところがあるの
PWA Night vol.57 ～認証・認可〜 にてパスキーの話をしました - r-weblife
ritou です。 これで話しました。 pwanight.connpass.com 発表資料と発表内容を公開します。 発表資料 speakerdeck.com 発表内容 台本チラ見しながら話したので実際にはこのとおりになってなかった部分もあります。 今日は、パスキーについて話します。 細かい自己紹介は省略します。 色々宣伝したいものがありますがブログに書きます。 今日の内容ですが、初めにパスキーの概要についてざっと触れます。 続いてWebアプリケーションにパスキーを導入するとなった場合にどこから手をつけるべきかというところに触れた後、一番の悩みどころになりそうなログインのUI/UXについて紹介します。 概要からいきましょう。 パスキーの紹介記事もたくさん出ているので要点だけまとめます。 パスキーとは「パスワードが不要な認証方式」であり、それを支える仕様はFIDOアライアンスとW3Cにより策
FIDOの最新動向から考える巨大プラットフォーマーとの関係 - r-weblife
おはようございます、ritouです。 Google I/O の "A path to a world without passwords" っていう発表、ご覧になりましたか？ www.youtube.com FIDO, WebOTP, FedCM...いいネタ揃ってますね！今回はFIDOの話をしましょう。 パスワード認証はもう終わり！時代はパスワードレス認証ですよと言い続けてはや数年経ちましたが、最近こんなプレスリリースが出ていました。 prtimes.jp すべての人にとってウェブをより安全で使いやすいものにするための共同の取り組みとして、Apple、Google、Microsoftは本日、FIDOアライアンスとWorld Wide Web Consortium（以下、W3C）が策定した共通のパスワードレス認証のサポートを拡大する計画を発表しました。 何やら大ごと感ありますが、3行でまと
OAuth 2.0等のRFC番号が飛び交う会話についていくためのカード [PR] - r-weblife
こんにちは、ritouです。 私は以前からこういうTweetをしていました。 エヴァンジェリストたるもの、日頃の研鑽を欠かさないのである… pic.twitter.com/5moTCOe6CF— 👹秋田の猫🐱 (@ritou) 2019年1月4日 このような日々の努力の結果、いわゆる「RFC番号が飛び交う会話」を身に付けたのです。 そして、このハードルを初学者が乗り越えていくために何ができるかを考えました。 その結果思いついたのが「ID-RFCカード」です。 r-weblife.booth.pm 何かというと、まず、RFC番号とタイトルの組み合わせをバーっと並べた「仕様カード」があります。 そして、RFC番号とざっくりな概要の組み合わせをバーっと並べた「解説カード」があります。 対象のRFCはIETFの OAuth JOSE COSE SCIM のWGで仕様策定されたものと、WebFi
![OAuth 2.0等のRFC番号が飛び交う会話についていくためのカード [PR] - r-weblife](https://cdn-ak-scissors.b.st-hatena.com/image/square/4bc17b49644452bf2e29b528b8c8d7e17921f71b/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fr%2Fritou%2F20211004%2F20211004023232.jpg)
JWT+RDBを用いたOAuth 2.0 ハイブリッド型トークンの実装例 - r-weblife
おはようございます、ritouです。 (⚠️認可イベントの識別子のあたり、ちょっと見直しました！最初に見ていただいた方はもう一回どうぞ！) 前回、ハイブリッド型と呼ばれる OAuth 2.0 のトークン実装について書きました。 ritou.hatenablog.com その続きとして JWT(JWS) + RDBでできる実装例を紹介します。 理解するにはそれなりの OAuth 2.0 に関する知識が必要になるかもしれませんが、よかったら参考にしてみてください。 何を考えたのか OAuth 2.0のRefresh Token, Access Tokenを考えます。 要件から整理しましょう。 要件 結構ありますが、最低限の OAuth 2.0 の Authorization Server を実装しようと思ったらこれぐらいはやらないといけないでしょう。 RFC6750 で定義されている Bear
OAuth 2.0/OIDCに入門した開発者が仕様沼に潜るための次のステップとは？ - r-weblife
お疲れ様です、ritou です。 OAuth 2.0やOIDCの入門書(?)を読み終えた開発者の方に、仕様を理解していくための次のステップは何があるかを聞かれました。 そもそもそんなこと言う人は クライアントを実装したい(しなければならない) 認可サーバーを実装したい(しなければならない) セキュリティエンジニアを名乗っていてこの分野を抑えときたい ただ単純に興味がある : そんな人いる？ とかそんな感じな気はしますが、基本的なフローを乗り越えた先に広がる仕様沼への潜り方に戸惑っておられるようでした。 そこで、いわゆる RFC6749/6750/7636 あたりを完全に理解した開発者が山ほどある仕様にどう立ち向かっていくかを考えます。 仕様にも色々ある IETF の OAuth関連の仕様、いっぱいあります。密です。密です。みみみみみみみみ... tools.ietf.org 去年に一回まと
OAuth 2.0/OpenID Connectで使われるBindingの仕組みについて整理する - r-weblife
おはようございます、OAuth警察を装っている ritou です。 qiita.com 認証認可技術 Advent Calendar 2019 2日目の記事です。 今日もやっていきましょう。 (2020/3/9追記)本投稿の内容をさらにわかりやすく整理された本を @authyasan さんが書かれています。 #技術書典 応援祭の新刊をBOOTHで公開！ OAuth・OIDCへの攻撃と対策を整理して理解できる本（リダイレクトへの攻撃編 https://t.co/OtNRNQGmOJ 以下について学びたい方はぜひお読みください state nonce PKCE c_hash at_hash CSRF リプレイ攻撃 認可コード横取り攻撃 トークン・コードインジェクション— Auth屋@技術書典応援祭を応援！OAuthへの攻撃本執筆中 (@authyasan) 2020年3月7日 私もレビューをさ
GitHubの2要素認証がWebAuthnに対応したらしいので触ってみた - r-weblife
どーも、ritouです。 世の中みんながこの話題に夢中かと思います(大げさ)。 github.blog GitHubは以前から2要素認証の方式としてセキュリティキーをサポートしてきました。2015年ですって。 github.blog 今回、その実装がWebAuthnに変更になったということです。 forest.watch.impress.co.jp 将来的には“Windows Hello”や“Touch ID”などもサポートされるという。 Windows HelloやmacOSのChromeなどを用いたTouch IDが利用可能になるのは、将来の話ではありません。もう対応しています。 www.publickey1.jp この記事はパスワードレスを実現したかのような書きっぷり。 WebAuthnはパスワードレスを実現するための仕組みだが、今回のGitHubの対応は用途を2要素目の認証方法に限
OAuth 2.0 Implicit Flowをユーザー認証に利用する際のリスクと対策方法について #idcon - r-weblife
おはようございます、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
OAuth 2.0の概要 - r-weblife
Eran がエントリ書いてました。 http://hueniverse.com/2010/05/introducing-oauth-2-0/ 今回の内容は翻訳ではありません。 読みながら感じたことを書き連ねたものです。 ■ なぜ新しいバージョンを考え始めたのか？OAuth 1.0aの課題 Eranは3つのポイントを挙げています。 Authentication and Signatures OAuthの実装にわずかでも関わった開発者が感じるのは、署名が面倒だということではないでしょうか？ twitterでBasic認証からOAuth/xAuthへの移行に苦労されている開発者の方もいると思いますが、やっぱり工数かかりますよね。 （まぁ、それでも独自でSP達が全部考えた仕様にかなり作りこんで対応するよりは、まだましかとおもいますけど？） これを、HTTPSを使ってSecretそのままでとことん簡
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
