JWTのalg=noneによる署名検証回避はどうして起こるのか
おはようございます。ritouです。 なんの話？ これの話です。 RFC 8725 JSON Web Token Best Current Practices をざっくり解説する - Qiita 攻撃者が none に書き換え、検証側がそれを信用して署名検証をスキップ : ライブラリが JWT Header の alg の値を信用して署名検証をスキップしてしまうお話です 攻撃者が RS256 を HS256 に書き換え、検証側は RSA 公開鍵を HMAC の共有鍵として署名検証 : こちらも JWT Header の alg の値を信用し、署名検証用の関数の引数として指定したRSA公開鍵を共有鍵として扱ってしまうお話です どっちも「おいおい冗談だろ」みたいなお話に見えますが、そういう実装もあるのが事実なんですね。 どうしてこうなった？ 署名検証ロジックが JWT文字列と鍵情報をパラメータ
midPoint The Bookの紹介と翻訳版の公開 - Qiita
NRI OpenStandia Advent Calendar 2020の1日目は、IGAを実現するオープンソースmidPointの技術書「Practical Identity Management with MidPoint」とその翻訳活動の紹介をします。 midPointとは？ これまでQiitaやOpenStandiaのホームページでも何度かご紹介していますが、改めてmidPointとは何なのか簡単にご説明します。midPointはIDM（ID管理）、IGA（IDガバナンス&アドミニストレーション）を実現するオープンソースソフトウェアです。スロバキアのEvolveum社が開発を主導しており、NRIもパートナーシップ契約を締結しサポートを提供しています。完全なオープンソースであること、IGA（IDガバナンス&アドミニストレーション）を実現できることが特徴のソフトウェアです。 midPo
Internet Identity Workshop（Fall 2019）に初めて参加してきた話 - Got Some \W+ech?
ちょっと真面目にIdentity系に集中しようと思い、今年の5月にEuropean Identity Conferenceに行ったところ、 プロの方に「Internet Identity Workshopにも行ったほうがいい」と進められたので、ほいほい来てしまった話をします。 IIWとは IIWは毎年２回、マウンテンビューで開催されるアイデンティティ関係の「アン（Un）カンファレンス」です。 アンカンファレンスが何かと言うと、一言でいうとカンファレンス形式ではない会合みたいなものです。 通常のカンファレンスですと、事前にカテゴリーを決定し、CfPと審査を経てコンテンツが決定されます。 一方、アンカンファレンスでは、そのような事前準備はありません。当日に、参加者が話したい内容を提案し、その聞きたい内容がホスティングされている部屋におもむくような形で進行されます。 具体的には、まず朝09:00
OpenID 2.0 Shutdown Timetable | OpenID 2.0 (Migration) - Google Accounts Authentication and Authorization — Google Developers
Google の OAuth 2.0 API は認証と認可の両方に使用できます。このドキュメントでは、OpenID Connect 仕様に準拠し、OpenID Certified を受けている、認証用の OAuth 2.0 実装について説明します。このサービスには、OAuth 2.0 を使用した Google API へのアクセスのドキュメントも適用されます。このプロトコルをインタラクティブに試すには、Google OAuth 2.0 Playground の使用をおすすめします。 Stack Overflow でヘルプを表示するには、質問に「google-oauth」のタグを付けます。 OAuth 2.0 の設定 アプリケーションでユーザー ログインに Google の OAuth 2.0 認証システムを使用するには、 Google API Console でプロジェクトを設定し、OAu
AWS IAM Access Analyzerによる継続的ポリシーチェックを自動化する方法 - Qiita
はじめに AWSのIAMロールに付与するIAMポリシーの権限は、セキュリティリスクを考えれば、必要最小限にとどめる必要があります。 AWSの任意のインスタンスに関連付けられたIAMロールでは、設定時は最小権限になっていても、その後の運用で過剰な権限が付与される可能性があります。 また、開発者や運用者が作るIAMポリシーの権限も、必ずセキュリティベストプラクティスに沿っているかどうかは分かりません。 このIAMポリシーの検査を継続的に実施可能な環境を作るために、自動化されたメカニズムの導入を検討します。 アプローチ AWS IAM Access Analyzerには、IAMポリシーのチェック機能があり、この機能を利用してポリシーを検証できます。 マネジメントコンソール上だけではなく、AWS CLIやSDKでも実行可能であり、自動化できます。 IAM Access Analyzerのポリシーチ
マイナンバーカードでmacOSにログイン - AAA Blog
先日、OpenSC 0.17.0がリリースされました。 これはマイナンバーカード内の証明書を扱うためのJPKIドライバが付属した最初のリリースとなります。 まだいくつか既知の問題を残しているのですが、Windows,Mac,Linuxなど様々なプラットフォームでJPKIを利用できる環境が整いつつあります。 今回はマイナンバーカードで自分のMacOSにログインしたり、スクリーンロックを解除する方法を紹介します。 JPKIドライバの開発状況PKCS#11 APIはほとんどの機能が動作するようになりました。SSHやPAM、Firefoxからは問題なく利用できるでしょう。 しかし、MacOSで証明書を利用するにはCDSA/Tokendに対応する必要があります。 これはもはやレガシーなフレームワークで、マイナンバーカードの証明書を扱う際にやっかいな問題があったのですが、このたび認証用証明書だけは問題
認証/認可基盤PERMANの紹介 | CyberAgent Developers Blog
みなさま、こんにちは、こんばんはokzkと申します。 数年前にはAmebaの画像基盤でストレージを超ガンバッてた輩です。 今回は、内製の認証認可基盤のPERMANを紹介します。 PERMANって？ Permission Managerからとって、PERMANです。 (藤子不二雄先生の漫画とは一切関係ないです) 簡単にいうと認証/認可基盤ですが、難しい言葉でいうと、Identity Governance & Administration(IGA)に分類されるシステムです。 ユーザサービス向けではなく社内向けのサービスとなっています。 具体的にはRBAC(Role Base Access Control)を志向していて、なんか色々対応しています。 整理せずに、ざっと例を上げると以下のようなカンジです。 SAML2(AWS, Google, AzureAD, Slack, GitHub, その他
シングルサインオンの歴史とSAMLへの道のり
The document discusses Amazon Web Services (AWS) Batch and how it can help customers run batch computing workloads on AWS. It notes that AWS Batch automatically provisions the optimal quantity and type of compute resources (e.g., EC2 instances) required to run jobs efficiently. It also allows customers to integrate their own scheduling and application code with AWS Batch through simple API calls o
やはりお前らの多要素認証は間違っている | DevelopersIO
よく訓練されたアップル信者、都元です。 いきなりガン煽りのタイトルで申し訳ないんですが、これしか頭に浮かびませんでした。 ちなみに原作は見たことがありません。 弊社は本日を最終営業日として、これから冬季休業となります。 今年も一年、どうもありがとうございました。というわけで書き納めの一本、その2。 さて、「認証」という言葉がありますが、要するに 相手が誰（何）であるかを確認すること を表します。 正確には「ひとつのデジタルアイデンティティがある実体に対応することの確証を得ること」です。 が、まぁそれはまた別のお話。 この「認証」はなにもコンピュータに限定した話ではなく、人間同士のコミュニケーションでも 随時行っている話です。目の前で自分と会話している人物が、本当に自分が望んでいる相手かどうか、 というのは確信できていると思います。 結論 さていきなりの結論ですが。実は単要素なのに、二要素認
認証にまつわるセキュリティの新常識 - Speaker Deck
2016-2017年でのNIST SP800-63-3改定を通じて、認証を含むデジタルアイデンティティの世界では様々な議論が湧き起こりました。 そんな本ガイドラインの内容を通じて、デジタルアイデンティティフレームワークを考える上での共通言語、特に「認証方法」について記載したNIST SP800-63Bについての理解と体得を試みつつ、議論になったいくつかのテーマについて取り上げて、この領域の面白さに触れてみます。 [rev3] 2022年1月までのアップデートを追加して、個別依頼を受けて実施したプライベートセミナー向けの版をサニタイズしてアップロードしました。〆切ドリブンで改定機会をくださった会社様には感謝です。 主な改定 ・SMSへの攻撃としてSS7とSakari/Bandwidth社の事例 ・よくある追加認証のトピックス ・アカウントリカバリの文言改善（解釈文書を元に） ・NIST SP
【第二弾】OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
はじめに 本記事は「OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る」の続編となります。保護リソースエンドポイント (protected resource endpoint)、いわゆる世の中でいうところの (狭義の) Web API の実装に関する話題がメインとなります。 1. もう一つの認可 1.1. アカウント属性文脈での認可 混乱を避けるため前記事では敢えて言及しませんでしたが、認可という言葉は別の文脈で使われることがあります。その文脈では、「誰が何の権限を持っているか (who has what permissions)」という情報を扱うために認可という言葉を使います。これは、OAuth の文脈での認可「誰が誰に何の権限を与えるか (who grants what permissions to whom)」とは異なります。厄介なことに、このど
マイクロサービスにおける内部通信の認証について
"Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~"の発表資料です。 https://connpass.com/event/142624/
OpenID Connect の JWT の署名を自力で検証してみると見えてきた公開鍵暗号の実装の話 - Qiita
はじめに 皆さん、OpenID Connect を使った Web 認証/認可システムを実装していて、「サードパーティのライブラリなんかに頼りたくない！」とか「署名を自分でパースして中身見てみたい！」とか「OpenSSL の RSA_verify 呼び出すだけじゃ物足りない！自分で $m = S^e \pmod{n}$ ってやって署名検証してみたい！」って思うことよくありますよね？ ここでは、暗号関連のライブラリを使用せず、OpenID Connect の JWT の署名を自力で 検証した際に調べた内容を備忘録としてまとめてみました。 普通はライブラリ任せにする署名検証の処理も自力でやってるので、「RSA 暗号の数式も知ってるし、ライブラリ使えば暗号化もできる。だけど、平文として指定した hogehoge をどうやってあの数式に当てはめてるのか気になる」という人が読むと、もしかしたら嬉しいか
「ID TokenをAuthorization Headerにつけて送る」というお作法について思うところ - r-weblife
こんばんは、ritouです。 ID Tokenがやりとりされている背景 ちょっと前にこんな話がありました。 blog.ssrf.in この id_token が JWT になっていますので、これを Authorization: Bearer $ID_TOKEN というヘッダにして oauth2-proxy で保護されているアプリケーションへ送信するだけです。 docs.aws.amazon.com Authorization ヘッダー (または、オーソライザー作成時に指定した別のヘッダー) に ID トークンを含めます。 この「ID TokenをAuthorization Headerに指定して保護されているっぽいリソースにアクセスする行為」は一体何なのかというお話です。 ある有識者はOAuth 2.0のProtected ResourceをID Tokenで保護することについての投稿をし
OAuth 2.1 の標準化が進められています - Qiita
IETFのOAuth WGでは、今あるOAuth2.0関連の仕様を整理し、一つの仕様としてまとめなおし OAuth2.1 として標準化するとりくみが進められています。 今回は、簡単にOAuth2.1について紹介します。 OAuth 2.0 OAuth 2.0は2012年10月に「RFC6749 The OAuth 2.0 Authorization Framework」として標準化されています。その後、OAuth2.0の改善は続けられ、セキュリティ向上のために利用すべき機能(PKCE)などが追加されているほか、逆に非推奨になっている機能(Implicit Grant)などがあります。 IETFのOAuth WGではOAuth2.0を安全に利用するためのベストカレントプラクティスを「OAuth 2.0 Security Best Current Practice」としてまとめています。 この
パスワードのない未来のための Firebaseで実装するFIDO2 / FIDO2 actualized by Firebase for the password-less future
FIDO（ファイド）はユーザーの認証をローカルで行うため、ユーザーの識別情報がネットワーク上でやりとりされないセキュアなプロトコルです。 ユーザーからのメリットとしてはパスワードを覚える必要がなくワンタップで簡単にログインできますが、実装に関する情報はまだまだ少ないのが現状です。 本トークではサードパーティ認証を使わず、ファーストパーティ認証としてどのようにAndroidアプリにFIDO2を実装し運用していくかについて紹介します。 デモにはFirebase AuthenticationとCloud Functionsを利用します。 サーバーサイドはNode.jsで実装を行います。 https://line.connpass.com/event/173284/
AWSコンソールにOktaでSSOする – ひろかずのブログ
こんにちは、ひろかずです 俺でもできたアドベントカレンダー2018に参加です。 アドベントカレンダー初体験です。 AWSコンソールにID/PW/2FAで入るのってそろそろしんどくなってきたので、OktaでSSOすることにしました。 需要はあると思うので、一筆書きます。 前提条件 Oktaのライセンスが購入済みであること Oktaと認証基盤は接続済みであること 参考ドキュメント Okta公式 - How to Configure SAML 2.0 for Amazon Web Service 工程 Oktaでメタデータを取得 AWSアカウントにOktaをIdPとして登録 SSOに利用するIAMロールを作成 OktaでAWSへSSOするアプリケーションの設定 1. Oktaでメタデータを取得 Okta管理者画面の[Applications]タブを選択して、[Add Application]ボタ
G Suite アカウントを用いた AWS へのシングルサインオン | Amazon Web Services
AWS Startup ブログ G Suite アカウントを用いた AWS へのシングルサインオン 皆さん、こんにちは。Startup Solutions Architect の松田です。 今回はセキュリティのお話です。今日、お客様は AWS のマネジメントコンソールへのログインのセキィリティを強化するために、様々な選択肢をお選びいただくことが可能になっています。一部のお客様は IAM User の管理を楽にするために、外部サービスのアカウントを用いて AWS のマネジメントコンソールへのログインを行っております。 この手法がスタートアップにとって有用なセキュリティオプションとなる場合が多くあります。例えば、フリーランスのエンジニアやインターンなど人の出入りが激しいスタートアップにとって、アカウントを一元管理出来ることはセキュリティの向上に繋がります。あるいは非エンジニアの社員が Amaz
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
課金関連の基礎技術: 認証やセキュリティにまつわる最新動向や標準化について
AWS SSOとGoogle Idpのおいしい関係 ~ QuickSightに楽してログインしたい ~
