OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife
こんばんは。ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。 qiita.com 初日なのでゆるふわな話をしましょう。 何の話か もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。 社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた 認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS— greenspa (@greenspa) 2020年9月28日 このbotに対する思うところはもう良いです。 今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAut
OAuth 2.0 クライアント認証 - Qiita
はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。
OAuth 2.0 の Client Type についての考え方
ritou です。 OAuth 2.0 のクライアントの種類、いわゆる Client Type についての基本的なお話です。 よくある認識 仕様だと Public : ClientSecret を安全に管理できず、他の方法でもセキュアなクライアント認証ができないクライアント Confidential : ClientSecret を安全に管理できる、または他の方法でセキュアなクライアント認証ができるクライアント と書いてあり、実際の分類となると Webアプリ : Confidential モバイルアプリ、SPA、デスクトップアプリ : Public となります。 Webサーバーの内部など、ある程度アクセス制限のされた状態で管理されているが、SPAのソースコードやモバイルアプリのバイナリの解析とかによって取得しうるみたいなのは直感的かと思いますが、これだけだといろいろ迷う人がいるらしい、とい
パーフェクトRails著者が解説するdeviseの現代的なユーザー認証のモデル構成について - joker1007’s diary
最近、パーフェクトRuby on Railsの増補改訂版をリリースさせていただいた身なので、久しぶりにRailsについて書いてみようと思う。 まあ、書籍の宣伝みたいなものです。 数日前に、noteというサービスでWebフロント側に投稿者のIPアドレスが露出するという漏洩事故が起きました。これがどれぐらい問題かは一旦置いておいて、何故こういうことになるのか、そしてRailsでよく使われるdeviseという認証機構作成ライブラリのより良い使い方について話をしていきます。 (noteがRailsを使っているか、ここで話をするdeviseを採用しているかは定かではないので、ここから先の話はその事故とは直接関係ありません。Railsだったとしても恐らく使ってないか変な使い方してると思うんですが、理由は後述) 何故こんなことが起きるのか そもそも、フロント側に何故IPアドレスを送ってんだ、という話です
JWT 認証のメリットとセキュリティトレードオフの私感 - ..たれろぐ..
2020/5/9追記: 考えた結果、Authorization Bearer ヘッダを使った正規のJWTの場合、同一ドメイン下で読み込む全 JavaScript が信用できる場合でないとブラウザ上で安全にトークンを保持できないのでブラウザからのAPIアクセス時の認証用には使うべきではないというところに着陸しました。ブラウザからのアクセスでは http only cookie にトークンを入れ、 CSRF 対策も忘れずにというこれまで通りの定石が手堅いように思います。 JWTを使うのはトークンの安全な保管ができる非ブラウザなネイティブクライアントからのAPIアクセス時に限った方がよさそうです。 APIサーバ側ではアクセス元に合わせて認証方法を使い分ける両対応が要求されるので手間は増えますが手抜きできる場所でもないので仕方なしと。 React(SPA)での認証についてまとめ - エンジニアの本
Refresh Token： どのような場合に使用し、どのように JWT と相互作用するか
Auth0 Marketplace Discover and enable the integrations you need to solve identity Explore Auth0 Marketplace 本書では OAuth2 で定義されたRefresh Tokenの概念について学びます。また、Refresh Tokenと他のトークンタイプを比較して、その理由と方法を学びます。さらに、簡単な例を使ってRefresh Tokenの使い方について説明します。それでは、始めましょう！ 更新： 本書を書いた時点では、Auth0 は OpenID Connect 認証を取得していませんでした。本書では access token のような用語の一部は本仕様に準拠しませんが、 OAuth2 仕様には準拠しています。OpenID Connect は access token （Authoriz
JWT認証、便利やん？ - ブログ
どうして JWT をセッションに使っちゃうわけ？ - co3k.org に対して思うことを書く。 (ステートレスな) JWT をセッションに使うことは、セッション ID を用いる伝統的なセッション機構に比べて、あらゆるセキュリティ上のリスクを負うことになります。 と大口叩いておいて、それに続く理由がほとんどお粗末な運用によるものなのはどうなのか。最後に、 でもそこまでしてステートレスに JWT を使わなくてはいけないか？ とまで行っていますが、JWT認証のメリットはその実装のシンプルさとステートレスなことにあります。現実的には実際はDB参照とか必要になったりするんですが、ほとんど改ざん検証だけで済むのは魅力的です。トレードオフでリアルタイムでユーザー無効化ができないことくらいですかね。ライブラリなんて使う必要ないほどシンプルだし、トレードオフさえ許容できればむしろ、なぜこれ以上に複雑な認証
どうして JWT をセッションに使っちゃうわけ？ - co3k.org
備考 2018/09/21 22:15 追記 2018/09/20 12:10 に公開した「どうして JWT をセッションに使っちゃうわけ？」というタイトルが不適切だとご指摘をいただいています。 その意見はもっともだと思いますので、現在、適切となるようにタイトルを調整しています。 ご迷惑およびお騒がせをして大変申し訳ございません。 本文の表現についても改善の余地は大いにありそうですが、こちらは (すでにご意見を頂戴している関係で、) 主張が変わってしまわないように配慮しつつ慎重に調整させていただくかもしれません。 はあああ〜〜〜〜頼むからこちらも忙しいのでこんなエントリを書かせないでほしい (挨拶)。もしくは僕を暇にしてこういうエントリを書かせるためのプログラマーを募集しています (挨拶)。 JWT (JSON Web Token; RFC 7519) を充分なリスクの見積もりをせずセッシ
JWTをセッション管理に転用するのはあまり良いアイデアではない(認証だけならいいよ) - id:anatooのブログ
どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ - co3k.org JWT認証、便利やん？ - ブログ JWT 認証のメリットとセキュリティトレードオフの私感 - ..たれろぐ.. JWTをセッションに使うことに関して最近少し議論があったので、自分のお気持ちを表明したいと思います。 私は以前SPAを書く時にJWTをセッション管理に使おうとしたことがありましたが、仔細に検討していくとJWTをセッション管理に使うのは無意味にセキュリティ上のリスクを増やすだけで、伝統的なクッキーを使ったセッション管理を使った方が良いという結論に至りました。 前提を整理するためにあらかじめ前置きすると、「JWTをセッション管理に使う」というのは認証APIなどで返ってきたJWTをlocalstorageなどJavaScriptからアクセスできるストレージに保管しておいて、ajaxでサーバ
JWTを使った今どきのSPAの認証について | HiCustomer Lab - HiCustomer Developer's Blog
TL;DR JWTはCookieを使った認証の代わりに使うのはきつい。 コードを静的にホスティングしているSPAの話。 JWTの有効期間を長くすれば危険で、短くすればUXが犠牲になるというトレードオフがある。 AWS AmplifyはlocalStorageにJWTを保存 悪意のあるThird partyライブラリが混ざっていたらJWTを抜かれる。 yarn.lockが依存している全ライブラリを監査することはつらい。 Auth0ではiFrameを活用してメモリ上にJWTを格納できる Auth0いいね😍 まくら Youtubeが大好きなHiCustomerの小田です。ちょっと遅いですが年明け最初のエントリーです。今年もテックブログをよろしくお願いします😎ちなみに、気分がいいので年明けに観ていたYoutubeのエントリーの中で一番おもしろかった動画を紹介します。世界中で有名な「Auld L
AWS Dev Day Tokyo 2018 で「マイクロサービス時代の認証と認可」の話をしてきた #AWSDevDay | DevelopersIO
緊張すると声がヤムチャになる都元です。このセッションの自己紹介でアムロ・レイとか言って盛大にスベったので切り替えていきます！ さて、1週間の時間が経ってしまいましたが、去る 11/2 (金) に目黒セントラルスクエアにおいて「マイクロサービス時代の認証と認可」と題しましてお話をさせていただきました。 スライド 認証と認可の基礎知識 繰り返しになりますので、過去エントリーよくわかる認証と認可 ｜ DevelopersIO を参照してください。 また、Web API のアクセス制御としては、だいたい次の4つくらいが頭に浮かぶと思います。 Basic 認証 Digest 認証 リクエスト署名 OAuth 2.0 この辺りは Spring Day 2016 - Web API アクセス制御の最適解でお話したことがありますので、こちらも併せてご覧ください。 Coffee break: 都元、日頃のお
期待のSSH認証方式「STNS」を試す - Qiita
これは、2016年のアドベントカレンダーを書く時間がなかったときの、逃げ道に用意してあった記事です。 すっかりアップロードを忘れていました。 そのため、手元のタイムスタンプでは 2016/12/08最終更新 となってますのでご注意ください。 はじめに Linuxのユーザー管理にLDAPを使うのにうんざりしている人、いますよね。 RDB系と違って癖があるので、説明するのも大変だったりします。 STNSはそんな方々にとって理想的な代替手段になりそうなOSSです。 セットアップしてみる 上記の通り、この手順は 2016年12月頃に検証したログ です。 本手順を鵜呑みにせず、 必ず最新の情報を確認してからセットアップしてください。 試験環境はCentOS6です。 インストール インストール手順に従ってyumリポジトリが公開されています。 それを使用する場合はこちら。 ### バグがあると嫌なので、
stnsバックエンドでユーザを一元管理 - Qiita
はじめに stnsを使ってユーザ管理を一元化したので、その構築手順や実装例を紹介します。 STNSとは？ サーバにSSHログインする際に使用する公開鍵をtoml形式のファイル（もしくはstns I/Fを 持ったバックエンド）で提供することで、ユーザの設定状態を一元管理するためのツールです。 各サーバにOSユーザを作成する必要がなく、一元管理でき、利用者の増減（例えば、 入社、部署移動、退職など）を簡単に反映でき、運用の手間を減らせます。 こちらを読めば開発の動機、背景がわかります。 STNSバックエンドを自前で立てる理由 そもそもなぜ自前のバックエンドが必要かというと、stnsには標準でtoml形式でユーザ管理するバックエンドが 同梱されていますが、それを使う場合にtomlファイルをgit等で管理すること（情報の一元管理）はできますが、 結局各サーバにそのtomlを反映する必要があり、状態
【完全新機能】DB認証情報やOAuthキーを一元管理可能なAWS Secrets Managerが発表されました！ | DevelopersIO
現在開催されている、AWS Summits 2018 | San Franciscoにおいて、AWS Secrets Managerが発表されました。 AWS Secrets Manager: Store, Distribute, and Rotate Credentials Securely | AWS News Blog 2018年4月9日更新 AWS Secrets Managerを学ぶ時に便利なリソースや、概要、構造、チュートリアルなどをまとめた記事を公開しました。こちらも合わせて御覧ください。 機密情報を一元管理できる「AWS Secrets Manager」とは？概要と主要機能、動作原理、各種リソースまとめ __ （祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 Secrets Managerﾀﾞﾜｯｼｮｲ |_|＿| し'´Ｊ AWS Secrets Mana
Gunosy管理画面を支えるRails技術 - Gunosy Tech Blog
広告技術部の toshimaru です。この記事はGunosy Advent Calendarの24日目の記事です。 qiita.com はじめに Gunosyではいくつかの管理画面においてRuby on Rails（以降Rails）を利用しています。具体的には下記の管理画面においてRailsが利用されています。 社内メンバー向け管理画面: 社内の担当者が記事の管理を行ったり、Gunosyアプリのユーザーの管理を行ったりできる管理画面です メディア様向け管理画面: Gunosyに記事を提供していただいているメディア様向け管理画面で、レポート閲覧や記事管理を行うことができます 広告主様向け管理画面: Gunosy Adsに広告を配信していただいている広告様向けの管理画面で、広告出稿やレポート閲覧を行うことができます 今日はそんなGunosy管理画面を支えているRails技術をいくつかピックア
一番分かりやすい OAuth の説明 - Qiita
はじめに 過去三年間、技術者ではない方々に OAuth（オーオース）の説明を繰り返してきました※1,※2。その結果、OAuth をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。Authlete アカウント登録はこちら！ ※2：そして２回目の資金調達！→『AUTHLETE 凸版・NTTドコモベンチャーズ・MTIからプレシリーズA資金調達』(2018 年 2 月 15 日発表) 説明手順 （１）ユーザーのデータがあります。 （２）ユーザーのデータを管理するサーバーがあります。これを『リソースサーバ
OAuth 1.0 のほうが OAuth 2.0 より安全なの？ - Qiita
1. OAuth 2.0 and the Road to Hell OAuth 1.0 と OAuth 2.0 の違いを調べていると、そのうちに「OAuth 2.0 and the Road to Hell」(by Eran Hammer氏) という文書にたどり着きます。この文書は、OAuth 仕様策定作業で精力的に頑張っていた方が OAuth 2.0 を批判して怒りの脱退宣言をするという衝撃的な文書です。 「OAuth 2.0 は OAuth 1.0 よりも安全ではない」というのが彼の一番の主張です。そのため、OAuth サーバーの実装を検討している人がこの文書を読むと、OAuth 2.0 の採用をためらい、OAuth 1.0 の方を選択してしまうことがあります。 実際、Open Bank Project というプロジェクトの実装である OBP-API では、Wiki で次のように述べて
OAuth & OpenID Connect 関連仕様まとめ - Qiita
はじめに OAuth や OpenID Connect に関連する仕様を紹介していこうと思います。 仕様はたくさんあるものの、ほとんどオプショナルです。しかし、「認可サーバーを実装する際は、RFC 6749 だけではなく、認可コード横取り攻撃への対抗策である RFC 7636 も実装すべきである」* という点は強調しておきたいと思います。 * 「PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと」という記事もご参照ください。 1. OAuth 2.0 (RFC 6749) OAuth 2.0 の仕様の本体は RFC 6749 (The OAuth 2.0 Authorization Framework) です。RFC 6749 の解説記事は世の中にたくさんあるので、ここでは要点だけ手短に紹介します。 RFC 6749 は、アクセストークンを発行
ついでに認証周りを理解してGoogle AppsのSAMLでAWSへログインを設定してみる - Qiita
はじめに背景的なこと 結構前からですが、クラウドサービスを多く使ってシステムを作る機会が多くなりました。 当然一つのクラウドサービスだけではないので複数使ったりします メールや資料の共有とかも、もはやGoogle Apps For Workで完結します そういった流れの中でID,PW管理が非常に煩雑になり、且つ結構重要なセキュリティ項目になってたりします （AWSのID,PWとか外に出たらヤバイですよね） このクラウドサービスを当たり前に使うようになったこのご時世に、セキュアに効率的にアカウント管理をしようってなって色々調べたメモ的なまとめ。 こう言ったのを統合認証とかっていうのかな。 ちょっと間違った理解になってる可能性ありですが、、、まとめていきます まずはよく出てくる用語を整理する 統合認証とは 社内のシステムや複数のクラウドサービスを利用する際に各システムにそれぞれ認証を行うのでは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
STNS of the year