2023/10/05 Offersさんのイベントでの資料です。 https://offers.connpass.com/event/295782/ イベント後の満足度アンケート（5点満点）の結果は以下になります。 5点: 49% 4点: 39% 3点: 8% 2点: 4% こちらのスライドの内容は以下の本の抜粋になります。デモの内容、このスライドでは触れていないことについてご興味ある場合は以下の本をご参照ください。 https://authya.booth.pm/items/1296585 https://authya.booth.pm/items/1550861 本発表で扱っていないセキュリティに関しては以下の本がおすすめです。 https://authya.booth.pm/items/1877818 本の評判 https://togetter.com/li/1477483
SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか？ - IDトークン自体にも、個人の属性（氏名等）情報は無いことを確認している - サーバーサイドでIDトークンの署名検証をして、IDトークンの改ざんが無いか確認する - Http Only属性：JSによるCookieへのアクセスを防ぐため - Secure属性：流出防止のため - SameSite=strict：CSRF対策のため 結論から言えば、「どちらでもよい」となります。しかし、恐らく話は
GitLabで1クリックアカウント乗っ取りが可能だった脆弱性から学ぶ、OpenID Connect実装の注意点 - Flatt Security Blog
はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの森(@ei01241)です。 最近は認証や認可に際してOpenID Connectを使うWebサービスが増えていると思います。「Googleアカウント/Twitter/Facebookでログイン」などのUIはあらゆるサービスで見かけると思います。しかし、OpenID Connectの仕様をよく理解せずに不適切な実装を行うと脆弱性を埋め込むことがあります。 そこで、突然ですがクイズです。以下のTweetをご覧ください。 ⚡️突然ですがクイズです！⚡️ 以下の画面はOAuth 2.0 Best Practice上は推奨されないような実装になっており、潜在的リスクがあります。https://t.co/bXGWktj5fx どのようなリスクが潜んでいるか、ぜひ考えてみてください。このリスクを用いた攻撃についての解説記
フルスクラッチして理解するOpenID Connect (1) 認可エンドポイント編 - エムスリーテックブログ
こんにちは。デジカルチームの末永(asmsuechan)です。 この記事では、OpenID Connect の ID Provider を標準ライブラリ縛りでフルスクラッチすることで OpenID Connect の仕様を理解することを目指します。実装言語は TypeScript です。 記事のボリュームを減らすため、OpenID Connect の全ての仕様を網羅した実装はせず、よく使われる一部の仕様のみをピックアップして実装します。この記事は全4回中の第1回となります。 なお、ここで実装する ID Provider は弊社内で使われているものではなく、筆者が趣味として作ったものです。ですので本番環境で使用されることを想定したものではありません。なんなら私は ID Provider を運用する仕事もしておりません。 1 OAuth 2.0 と OpenID Connect 1.1 用語の
こんにちは。デジカルチームの末永(asmsuechan)です。この記事は「フルスクラッチして理解するOpenID Connect」の全4記事中の3記事目です。前回はこちら。 www.m3tech.blog 9 JWT の実装 9.1 JWT概説 9.2 OpenID Connect の JWT 9.3 ヘッダーとペイロードの実装 9.4 署名の実装 公開鍵と秘密鍵を生成する 署名処理を作る 10 JWKS URI の実装 (GET /openid-connect/jwks) 11 RelyingParty で ID トークンの検証をする 12 OpenID Connect Discovery エンドポイントの実装 (GET /openid-connect/.well-known/openid-configuration) まとめ We're hiring 今回は全4回中の第3回目です。 (
GitHub Actions から AWS へのアクセスに利用している OpenID Connect ID Provider の thumbprint について調査した - ROUTE06 Tech Blog
ROUTE06 でエンジニアリングマネージャ兼ソフトウェアエンジニアとして働いております海老沢 (@satococoa) と申します。 先日発生した GitHub Actions と AWS の OpenID Connect 連携におけるトラブルに関して調査を行い、対応方針を策定した件を共有したいと思います。 [2023/07/10 追記] Thumbprint を明示的にユーザ側で設定しなくて良いように、AWS 側で対応されたそうです。 github.com 当面 Terraform のモジュール的には必須入力のままですが、任意の文字列で良いそうです。 （いずれ入力も不要になるのかと思います。） https://github.com/aws-actions/configure-aws-credentials/issues/357#issuecomment-1626357333 The A
Linux Daily Topics Linux Foundation、OpenID Connectを拡張した暗号化プロトコル「OpenPubkey」をローンチ Linux Foundationは10月4日（米国時間）、BastionZeroおよびDockerとともに暗号化プロトコルのオープンソースプロジェクト「OpenPubkey」をローンチすることを発表した。 Linux Foundation, BastionZero and Docker Announce the Launch of the OpenPubkey Project -linuxfoundation.org The Linux Foundation, BastionZero and Docker are excited to announce the launch of OpenPubkey as a Linux
フルスクラッチして理解するOpenID Connect (2) トークンエンドポイント編 - エムスリーテックブログ
こんにちは。デジカルチームの末永(asmsuechan)です。この記事は「フルスクラッチして理解するOpenID Connect」の2記事目です。前回はこちら。 www.m3tech.blog 7. トークンエンドポイントの実装(POST /openid-connect/token) 7.1 アクセストークン 例 7.2 ID トークン 例 7.3 IDトークンを返す部分を作る 7.4 アクセストークンを返す 7.5 パラメーターの検証 7.6 認可コードの検証 7.7 クライアント認証 8 イントロスペクションエンドポイントを作る(POST /openid-connect/introspect) まとめ We're hiring 今回は全4回中の第2回目です。 (1) 認可エンドポイント編 (2) トークンエンドポイント編 (3) JWT編 (4) stateとnonce編 7. トーク
フルスクラッチして理解するOpenID Connect (4) stateとnonce編 - エムスリーテックブログ
こんにちは。デジカルチームの末永(asmsuechan)です。この記事は「フルスクラッチして理解するOpenID Connect」の4記事目です。前回はこちら。 www.m3tech.blog 13 state の実装 14 nonce の実装 15 まとめ 16 参考 Wre're hiring! 今回は全4回中の第4回目です。 (1) 認可エンドポイント編 (2) トークンエンドポイント編 (3) JWT編 (4) stateとnonce編 13 state の実装 https://openid-foundation-japan.github.io/rfc6819.ja.html#anchor15 https://openid-foundation-japan.github.io/rfc6749.ja.html#CSRF state は OAuth 由来の仕様です。つまりアクセストーク
"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." という記述の解釈 というあたりからこのような表現になっているのでしょう。 ただ、この前提でプロトコル自体を解説、理解しようとすると何かうまくいかないところがあるの
ritouです。 某イベントのこの辺で出てくる質問に回答してみました。 Q. SAMLとの違い A. OAuthとは目的/用途が異なる。OIDCとの比較では、SAMLをモダンにしたのがOIDCという認識でおk。XML->JSON, XML Signature->JWTみたいな仕様の違いがある。あとはOIDCはSPAやモバイルアプリ、Verifiable Credentialsといった世の中の動向に追従して現在進行形で拡張仕様やプロファイル、ベストプラクティスの策定が進められている。 Q. 言葉の定義 A. 英語では決まっている。日本語に変換するときにおかしくなったり、IDaaSなどでOIDCをそのまま適用していない場合などで用語の混乱が起こりうる。 Q. 人間が介在しない認証フローではImplicit?非推奨？ A. おそらくClientCredentialsの方が適している Q. Con
こんばんは、ritouです。 タイトルの通り、お話をしてきました。 それではどうぞ。 動画 (2024/4/12: 動画が公開されていたので追記しました) 内容 OIDF-Jでエバンジェリストをしています。ritouです。 今日はパスキーとID連携についてお話させていただきます。 この発表では次の3点について話します。 それぞれの特徴/特性 ID連携のIdP/RPそれぞれがパスキー認証をサポートすることで得られるもの 関連するOIDC/OAuth 2.0の仕様 まずはそれぞれの特徴、特性から見ていきます。 パスキー、具体的には「FIDOクレデンシャルを用いた認証方式」について、特徴を振り返ります。 まずは公開鍵暗号を利用すること、ブラウザなどの仲介によるフィッシング耐性による安全性です。 そして、利用者の確認としてローカル認証と呼ばれる画面ロック解除の仕組みを利用すること、各プラットフォー
GitHub - zitadel/oidc: Easy to use OpenID Connect client and server library written for Go and certified by the OpenID Foundation
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
OpenID Connectを拡張した暗号化プロトコル「OpenPubkey」とは Linux Foundationなどが発表
Linux Foundationは2023年10月4日（米国時間）、BastionZeroやDockerとともに暗号化プロトコルのオープンソースプロジェクト「OpenPubkey」を発表した。OpenPubkeyの発表に合わせてBastionZeroは、Dockerコンテナ署名とOpenPubkeyの統合を発表している。 OpenPubkeyプロトコルとは？ OpenID Connectと何が違う？ BastionZeroによると、OpenPubkeyは、シングルサインオン（SSO）のデファクトスタンダードであるOpenID Connect（OIDC）にユーザーが生成した暗号署名を追加するプロトコルだ。 関連記事 Cloudflare、「CAPTCHA」に代わる「Turnstile」に完全移行、誰でも無制限に使える無料版も提供 Cloudflareは、同社が発行する全ての「CAPTCHA」
認証と認可はセキュリティを強化する上で欠かせない技術です。認証と認可を実現する技術として、OAuthやOpenID Connectがあります。OAuthは2012年に制定された認可のためのプロトコルです。このOAuthの拡張仕様として開発されたのが、認証のためのプロトコルであるOpenID Connectです。本記事では、OAuthとOpenID Connectの仕組みや特徴、違いについて解説します。 認証と認可とは OAuthやOpenID Connectを理解するためには、まず認証と認可について理解する必要があります。認証とは、通信の相手が「誰（何）であるのか」を確認・特定することです。認証には、ID・パスワードを使用する知識情報による認証、顔や指紋などを使用する生体情報による認証、SMSを使う所持情報をによる認証などがあります。それに対し、認可は、特定の条件下において、対象物（リソー
下記の仕様変更に追随するために更新。 クレデンシャルレスポンス暗号化関連のメタデータ群が credential_response_encryption という一つの JSON オブジェクトにまとめられた。 クレデンシャルレスポンスから format プロパティが削除された。 RAR オブジェクト内の format プロパティが復活した。 openid_credential タイプを持つ RAR オブジェクトは credential_configuration_id プロパティか format プロパティのどちらかを含まなければならなくなった。 クレデンシャルオファー内の credential_configurations プロパティが credential_configuration_ids へと名称変更された。 2. OID4VCI 仕様 OID4VCI 仕様は、Verifiable C
はじめに この記事は、「Digital Identity技術勉強会 #iddance Advent Calendar 2023」10日目の記事となります。 https://qiita.com/advent-calendar/2023/iddance OpenID Connect ムズカシイ… なんとなく、OpenID ConnectやOAuth2.0の仕様を勉強して、わからないなりに手を動かし、ググりまくり、実際にRP・OP側の実装経験らしきものを積んでくると お、これで自分も基本的な所は理解できてきたかな？ などと軽い気持ちで思い出した頃に、実装ミスや答えに窮する質問を受けて落ち込むもの。 自戒の意味も込めて、一般に言われていることが仕様上はどう記載されているかやTipsも含めて残していきたいと思います。 今回読んでいくのは「OpenID Connect Core 1.0」です。 はじめ
OpenID Configuration とは Google Microsoft Facebook Apple Yahoo! Japan LINE リクルート Slack PayPal その他 他にも見つけたら追記する。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
仕様が読めるようになるOAuth2.0、OpenID Connect 入門
SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか？ - IDトークン自体にも、個人の属性（氏名等）情報は無いことを確認している - サーバーサイドでIDトーク
フルスクラッチして理解するOpenID Connect (3) JWT編 - エムスリーテックブログ
Linux Foundation、OpenID Connectを拡張した暗号化プロトコル「OpenPubkey」をローンチ | gihyo.jp
"仕様が読めるようになるOAuthとOpenID Connect入門"の質問への回答
OpenID Summit Tokyo 2024 でパスキーとID連携について話しました
OAuthとOpenID Connectについて～仕組みや特徴など解説～
OpenID for Verifiable Credential Issuance - Authlete
OpenID Connectの仕様を改めて読み返してみる -
公開されている OpenID Configuration まとめ