oauth2とは何か？認証と認可の違い。
あぁ、しくじった。毎日書こうとしたら休みの日である事を完全に忘れてゲームばかりした結果 0時を回って書いてしまっている。 しかも今回の内容が多分長くなりそうだから既に明日やる口実を作って明日作成しようとしている。 あぁ、憂鬱だ。 そんな始まり方のoauth 最近でこそoauth認証って普及されてますけど、 最初見た時、？？？ってなりませんでしたか？ 僕は謎過ぎて良くわからなかったから、こんなのやらないと思ってました。 が、、、今になってみるとあまりにも便利が故に もはや、Googleサインインとかappleサインインが無いと嫌ですもんね。 おいおいおい、入れておけや。と。。。 それだけ楽にしてくれた認証機能ですが、 実は、認証機能以外にも認可という部分もあるので 今日はその辺を自分の備忘録的に書いていこうと思っています。 参考にしたもの まず先に参考にした動画を貼ります。 ざっくりと簡単に
Firebase Authentication 7つの落とし穴 - 脆弱性を生むIDaaSの不適切な利用 - Flatt Security Blog
はじめに こんにちは、株式会社 Flatt Security セキュリティエンジニアのぴざきゃっと (@pizzacat83) です。 認証機構を自作せずに導入できる Firebase Authentication は様々なアプリケーションにて利用されていますが、その特性を十分に理解せずに導入すると、実は不具合や脆弱性が生じることがあります。そこで本稿では Firebase Authentication を利用するうえで、注意しなければ不具合や脆弱性に繋がりうる 7 個の「落とし穴」について解説します。 はじめに IDaaS の利点と欠点 落とし穴 1. 自己サインアップ リスク 対策 不十分な対策 落とし穴 2. ユーザーが自身を削除できる 対策 落とし穴 3. 他人のメールアドレスを用いたユーザー登録 リスク リスク 3-1. メールアドレス誤入力によるユーザー乗っ取り リスク 3-2
ユーザー アカウント、認証、パスワード管理に関する 13 のベスト プラクティス2021 年版 | Google Cloud 公式ブログ
※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。 アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータ セキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。 幸い、Google Cloud には、ユーザー アカウント（ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー）の作成、安全な取り扱い、
よりよくわかる認証と認可 | DevelopersIO
少し早いですが、メリークリスマス！事業開発部の早川です。 早いもので、入社して 1 ヶ月半が経ちました。 現在は、 prismatix の理解を深めながら、導入支援を行っています。 今回はその中から、認証 / 認可についてお伝えします。 と言っても、これまでに同僚達が書いた分かりやすい記事がありますので、これらのガイダンスの形で、整理していきたいと思います。 ジョインしました 以来、初めての記事となりますﾄﾞｷﾄﾞｷ 目標 本記事をご覧いただいた後、こちらのスライドを何となく理解できる気がすることを目標とします。 本スライドに関するブログ記事はこちらです。 AWS Dev Day Tokyo 2018 で「マイクロサービス時代の認証と認可」の話をしてきた #AWSDevDay 目的 まず、認証 / 認可を学ぶ理由を考えてみました。 近年、様々なサービスが API を通じてつながり、より便利
セキュリティ視点からの JWT 入門 - blog of morioka12
こんにちは、ISC 1年 IPFactory 所属の morioka12 です。 この記事は IPFactory Advent Calendar 2020 の10日目の分になります。 IPFactory という技術サークルについては、こちらを参照ください。 本記事の最後に記載されている余談でも IPFactory の詳細を紹介しています。 はてなブログに投稿しました #はてなブログ IPFactory Advent Calendar 2020 の10日目の記事を書きました#JWT #security セキュリティ視点からの JWT 入門 - blog of morioka12https://t.co/g1MYe77hAF — morioka12 (@scgajge12) 2020年12月10日 普段は Web Security や Cloud Security 、バグバウンティなどを興味分
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
SSHの公開鍵認証における良くある誤解の話 - Qiita
はじめに 背景 これを知っていたからと言って何かの役に立つかというと、そうでない人の方が多いとは思うのですが、いい加減、SSHの公開鍵認証の説明がデマばかりなので、少しはちゃんとした説明もあった方が良いかもな、ということで記事にしました。 SSHについて 皆さんご存知の通り、SSHはSecureSHellの略であり、暗号によって保護された通信を通じて遠隔操作を行う1アプリケーション、またはプロトコル2を指します。 Linux等のUNIX系OSの遠隔操作3、またはネットワーク機器の管理に広く使われており、その実装としてはOpenSSHが有名です。 ところでSSHには、接続してきたユーザが誰なのかを識別する認証機能があり、その方式としてパスワード認証と並んで最もメジャーなのが公開鍵暗号を用いる公開鍵認証です。4 しかし…。残念なことに、公開鍵認証の設定や使い方はともかくとして、その仕組みに対す
パスワードの不要な世界はいかにして実現されるのか - FIDO2 と WebAuthn の基本を知る
不正送金やアカウントの乗っ取りなど、パスワードが原因の事件が後を絶ちません。高齢者など、IT リテラシの低い人でも簡単かつ安全に自分のオンラインアカウントを管理できる世界が理想ですが、まずはパスワードの不要な世界を実現するのが先決であることは、これまでのインターネットの歴史で証明されたと言えるでしょう。そして、ここに来てパスワード不要なログインを実現する技術として注目されているのが FIDO (= Fast IDentity Online, 「ファイド」) です。そしてその FIDO をブラウザから利用できるようにするのが WebAuthn (= Web Authentication、「ウェブオースン」)。報道内容などからこれらは指紋認証を実現するもの、と思っている人もいらっしゃるかもしれませんが、実際にはちょっと違います。 WebAuthn に関しては、すでに数多くの記事が出ていますので
まだログイン認証で消耗してるの？ ~ALBで簡単認証機構~ - Gunosy Tech Blog
こんにちは！広告技術部のUT@mocyutoです！ 最近はスマブラでなんのキャラを使おうか迷っています この記事はGunosy Advent Calender 19日目の記事です。 昨日の記事は@mathetakeのpeer-to-peerはGoogleの夢を見るかでした。 はじめに OIDC ALBの認証機能 一般的な認証機構 ALBを利用した認証 データフローの説明 実際の導入 APIでjwtから認証情報を取得する例 まとめ はじめに みなさんユーザ認証はどうやって作っていますか？ フレームワークを使って実装していますか？ それともイチから自前で作っていますか？ SSOのシステムとかはどうでしょう？ OIDCとAWSのALBを使えば簡単にユーザのログイン管理を作ることができます。 （少し煽り気味のタイトルですいません ;） OIDC OpenID Connect と言って、OAuth2
よくわかる認証と認可 | DevelopersIO
よく訓練されたアップル信者、都元です。「認証 認可」でググると保育園の話が山程出て来ます。が、今日は保育園の話ではありません。そちらを期待した方はごめんなさい。こちらからお帰りください。 さて、先日のDevelopers.IO 2016において、マイクロWebアプリケーションというテーマでお話させて頂きました。一言で言うと OAuth 2.0 と OpenID Connect 1.0 のお話だったのですが、これらを理解するにあたっては「認証」と「認可」をはっきりと別のものとしてクッキリと認識する必要があります。 まず、ざっくりとした理解 認証と認可は密接に絡み合っている一方で全く別の概念です。正直、理解は簡単ではないと思います。 まず「認証」は英語では Authentication と言います。長いので略して AuthN と書いたりすることもあります。意味としては 通信の相手が誰（何）であ
パスワードの定期的変更がセキュリティ対策として危険であること | まるおかディジタル株式会社
【これは約 16 分の記事です】 （2015年の投稿のため、リンク切れや情報が古くなっている部分が一部ございます） 定期的なパスワード変更を奨めるサービス提供者や行政 ID・パスワードが流出する事件を受け、提供者や行政提供者側からユーザに対してセキュリティ対策の実施を喚起しています。 IDとパスワードの適切な管理 ：警視庁（リング切れ） この中で、「パスワードの定期的変更」がうたわれています。このパスワードの定期変更については、セキュリティ対策として余り有効ではないという方は結構いらっしゃいます。 パスワードの定期的変更に関する徳丸の意見まとめ http://tumblr.tokumaru.org/post/38756508780/about-changing-passwords-regularly 実際、パスワードはどれくらいの頻度で変えるべきですか？ ｜ ライフハッカー［日本版］ ht
ログアウト機能の目的と実現方法
このエントリでは、Webアプリケーションにおけるログアウト機能に関連して、その目的と実現方法について説明します。 議論の前提 このエントリでは、認証方式として、いわゆるフォーム認証を前提としています。フォーム認証は俗な言い方かもしれませんが、HTMLフォームでIDとパスワードの入力フォームを作成し、その入力値をアプリケーション側で検証する認証方式のことです。IDとパスワードの入力は最初の1回ですませたいため、通常はCookieを用いて認証状態を保持します。ログアウト機能とは、保持された認証状態を破棄して、認証していない状態に戻すことです。 Cookieを用いた認証状態保持 前述のように、認証状態の保持にはCookieを用いることが一般的ですが、Cookieに auth=1 とか、userid=tokumaru などのように、ログイン状態を「そのまま」Cookieに保持すると脆弱性になります
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット＆ペーストアタックが可能だからです。 OAuth 認証？は、図１のような流れになります。 図１ OAuth 認証？の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A
PAMを利用して認証を行う
連載 Samba Tips！ Sambaユーザーのパスワード管理 PAMを利用して認証を行う ユーザー認証を実行するPAMシステムを利用すると、アプリケーションからユーザー認証を独立させることができる。このPAMをSambaと組み合わせることで、UNIXとSambaのパスワードの同期を行うことが可能だ。 今回はこのPAMを利用する方法について解説しよう 佐藤文優 <fumiya@samba.gr.jp> 株式会社デジタルデザイン 日本Sambaユーザ会 2000/6/21 PAMとは? 前回に引き続き、SambaパスワードとUNIXパスワードの同期を実現する方法について解説します。今回は、PAMを利用する方法を紹介しましょう。 PAM（Pluggable Authentication Module）とは、 各種の認証処理を実行するモジュール群と、 それを利用するための標準的なAPI（App
APIアクセス権を委譲するプロトコル、OAuthを知る ― ＠IT
クロスドメインでのデジタルアイデンティティを守る APIアクセス権を委譲するプロトコル、 OAuthを知る 作島 立樹 NRIパシフィック 2008/1/21 マッシュアップと呼ばれる仕組みで、既存のWebサービスが次々とつながり、新たなサービスが登場している。しかし、メールアドレスなど重要な個人情報が意図せずに「つながれてしまう」可能性もある。そこで登場したのがアクセス権の「委譲」を目的としたプロトコル、OAuthである。本記事ではOAuthの仕組みとともに、なぜそれが登場したのかという背景にも触れる（編集部） マッシュアップの犠牲になるユーザーのアイデンティティ GETなどのHTTPメソッドをもちいてURLへリクエストする、いわゆる「RESTful」【注1】なWeb APIを使ったアプリケーション同士の交流は、いままさに隆盛を極めている。「マッシュアップ」と呼ばれているこのサービス形態
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20110722/p01/