タグ

OAuthとsecurityに関するdamehumanのブックマーク (11)

  • 仕様が読めるようになるOAuth2.0、OpenID Connect 入門

    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

    仕様が読めるようになるOAuth2.0、OpenID Connect 入門
  • PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと - Qiita

    PKCE とは PKCE をご存知でしょうか? これは、今から一年ほど前の 2015 年 9 月に RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients) として公開された仕様を指しています。認可コード横取り攻撃 (authorization code interception attack) への対策として策定されました。 細かい条件は幾つかありますが、スマートフォンで OAuth クライアントを作る場合は、クライアント側も認可サーバー側もこの仕様の実装が強く推奨されます。これを実装しておかないと、悪意のあるアプリケーションに認可コードを横取りされてしまい、結果、悪意のあるアプリケーションがアクセストークンを取得できてしまいます。 この仕様自体のちょっとした解説は、「OAuth & OpenID Connect 関連仕

    PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと - Qiita
  • SPA認証トークンはlocalStorageでもCookieでもない、Auth0方式はいいねというお話 - @mizumotokのブログ

    SPA認証トークンをどこに保存するかは論争が絶えません。localStorageやCookieがよく使われますが、Auth0は違う方法を採用しています。この記事では、Auth0のトークン管理の方式を理解でき、トークン管理上のセキュリティへの理解を深めることができます。 SPAの認証トークンをどこに保存するか ブラウザでトークンを保存できる場所 保存場所の比較 メリット・デメリット Auth0のアプローチ トークンはインメモリに保存 OpenID Connect準拠とトークン取得のUI/UXの悪化回避を両立 Auth0のjsライブラリ ログイン アクセストークンの(再)取得 図解 ログイン アクセストークンの(再)取得 自サービス内の認証だけのもっと簡易な構成 ログイン IDトークン取得 まとめ SPAの認証トークンをどこに保存するか ReactVueで認証付きSPA(Single Pa

    SPA認証トークンはlocalStorageでもCookieでもない、Auth0方式はいいねというお話 - @mizumotokのブログ
  • OAuthの言葉周りを整理する

    OAuthの仕組みとToken認証周りの言葉はいつまで経ってもはっきり理解できないものの一つでした。 しかし最近ようやく理解できるようになってきたのでとりあえずそれぞれの言葉の指すものや定義をここで整理してみようと思います。 リフレッシュトークン リフレッシュトークンとは アクセストークンの有効期限が切れたときに、認可サーバーにアクセストークンの更新リクエスト認証をするためのトークン。 OAuth自体はリフレッシュトークンがなくとも実装できるが、リフレッシュトークンはOAuthをより便利にするためのもの。 一般的に有効期限は長い。 ないとどうなるのか アクセストークンの期限が切れたらその度にSNS認証のあのログイン画面に飛ばされてメアドとパスワードの入力が必要になる。 セキュリティに関すること 有効期限が長くても安全性に問題がないと考えられる理由としては、アクセストークンの期限切れ時にしか

    OAuthの言葉周りを整理する
  • サーバサイドでJWTの即時無効化機能を持っていないサービスは脆弱なのか? - くろの雑記帳

    きっかけ 昨年(2021年9月ごろ)に徳丸さんのこのツイートを見て、「2022年にはJWTを用いたセッション管理に代表される、ステートレスなセッション管理は世の中に受け入れられなくなっていくのだろうか?」と思っていました。 OWASP Top 10 2021 A1に「JWT tokens should be invalidated on the server after logout.」(私訳:JWTトークンはログアウト後にサーバー上で無効化すべきです)と書いてあるけど、どうやって無効化するんだ? ブラックリストに入れる?https://t.co/bcdldF82Bw— 徳丸 浩 (@ockeghem) 2021年9月10日 JWT大好きな皆さん、ここはウォッチしないとだめですよ。これがそのまま通ったら、ログアウト機能でJWTの即時無効化をしていないサイトは脆弱性診断で「OWASP Top

    サーバサイドでJWTの即時無効化機能を持っていないサービスは脆弱なのか? - くろの雑記帳
  • 「挫折しない OAuth / OpenID Connect 入門」のポイント - Authlete

    このビデオについて このビデオは、2021 年 10 月 6 日に開催された 「挫折しない OAuth / OpenID Connect 入門」の理解を深める会 のプレゼンテーション録画です。 2021 年 9 月 18 日発売の「Software Design 2021 年 10 月号」では、OAuth/OIDC が特集され、「挫折しない OAuth/OpenID Connect 入門・API を守る認証・認可フローのしくみ」と題し、Authlete 代表の川崎貴彦が寄稿しました。 プレゼンテーションでは記事のポイントや、理解を深めるために重要なポイントについて、著者の川崎がお話しします。 文字起こし はじめに 目次 記事の第1章、第2章、第3章は、こういう目次になっています。 ここからピックアップして、 こんなことを話してます、というところを、 紹介したいと思います。 自己紹介 Au

    「挫折しない OAuth / OpenID Connect 入門」のポイント - Authlete
  • ID連携の標準化仕様紹介とセキュアな実装のためのアプローチ ~ 2021 - r-weblife

    おはようございます ritou です。 久々に「解説付きスライド全公開」的なやつをやります。 先月、チーム内でID連携のための標準化仕様に関する勉強会(私が一方的に話す会)を行いました。 が、実際はだいぶグダグダになってしまい、これはその後色々付け足してるうちに別物になってしまった資料です。 内容としては、ID連携のための標準化仕様にどのようなものがあるかを知ってもらうための「入門編」のような立ち位置で作りました。 OpenID Connect(やSAMLのような) ID連携のための標準化仕様を紹介しようと思うと、ついつい個別にシーケンスやリクエスト/レスポンスの説明を始めがちですが、初学者が気になるのはそんな細けぇことではないでしょう。 まずは「この仕様で何ができるようになるのだろう」「この仕様では何を実現したいんだろう」と言うところから理解していくのが良いのではないでしょうか。 そこで

    ID連携の標準化仕様紹介とセキュアな実装のためのアプローチ ~ 2021 - r-weblife
  • OAuthにおける認可コード横取り攻撃とその対策

    OAuthにおける認可コード横取り攻撃とその対策 Jul 5, 2021 前回の記事で示したように、カスタムURLスキームを偽装した不正アプリは正規アプリへのディープリンクを乗っ取れる。この挙動の悪用シナリオとして、正規アプリと認可サーバー間のOAuthフローにおける認可コード横取り攻撃が知られている。この攻撃への対策を把握するためにiOS環境でシナリオを再現し、PKCEの有効性を確認した。 要約 OAuth 2.0の拡張機能であるPKCEを導入することで認可コード横取り攻撃を無効化できる。OAuth 2.0の仕様では、認可サーバーはネイティブアプリをクライアント認証できない。そのため、認可サーバーは認可コードを横取りした不正アプリと正規アプリを識別できない。しかし、PKCEの仕組みにより認可サーバーは正規アプリを識別できるようになり、認可コード横取り攻撃の検知が可能となる。 ネイティブア

    OAuthにおける認可コード横取り攻撃とその対策
  • よりよくわかる認証と認可 | DevelopersIO

    少し早いですが、メリークリスマス!事業開発部の早川です。 早いもので、入社して 1 ヶ月半が経ちました。 現在は、 prismatix の理解を深めながら、導入支援を行っています。 今回はその中から、認証 / 認可についてお伝えします。 と言っても、これまでに同僚達が書いた分かりやすい記事がありますので、これらのガイダンスの形で、整理していきたいと思います。 ジョインしました 以来、初めての記事となりますドキドキ 目標 記事をご覧いただいた後、こちらのスライドを何となく理解できる気がすることを目標とします。 スライドに関するブログ記事はこちらです。 AWS Dev Day Tokyo 2018 で「マイクロサービス時代の認証と認可」の話をしてきた #AWSDevDay 目的 まず、認証 / 認可を学ぶ理由を考えてみました。 近年、様々なサービスが API を通じてつながり、より便利

    よりよくわかる認証と認可 | DevelopersIO
  • トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita

    トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べたAPIOAuthWeb TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトークンを送る API あるよね、ああいうやつ 疑問 Authorization: Bearer ヘッダは OA

    トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
  • OAuth 2.0 をかみくだく

    Flink SQL: �the Challenges of Implementing a Streaming SQL Engine

    OAuth 2.0 をかみくだく
  • 1