Athorization framework for Ruby/Rails application
認可に関するtakaesuのブックマーク (16)
-
takaesu 2023/01/31
-
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
サーバーは、受け取ったクライアント証明書の主体識別情報が事前登録されているものと一致することを確認し、もってクライアント認証とします。 このクライアント認証方式には tls_client_auth という名前が与えられています（MTLS, 2.1.1. PKI Method Metadata Value）。 なお、クライアント証明書には OAuth 2.0 の文脈におけるクライアント ID は入っていないので、クライアント証明書だけではクライアントを特定することはできません。そのため、クライアント証明書を用いるクライアント認証をおこなう際は、別途クライアント ID をリクエストに含める必要があります。通常は client_id リクエストパラメーターが使用されます。 1.8. self_signed_tls_client_auth クライアント証明書を用いるクライアント認証において、PKI
-
OAuth 2.0 の Client Type についての考え方
ritou です。 OAuth 2.0 のクライアントの種類、いわゆる Client Type についての基本的なお話です。 よくある認識 仕様だと Public : ClientSecret を安全に管理できず、他の方法でもセキュアなクライアント認証ができないクライアント Confidential : ClientSecret を安全に管理できる、または他の方法でセキュアなクライアント認証ができるクライアント と書いてあり、実際の分類となると Webアプリ : Confidential モバイルアプリ、SPA、デスクトップアプリ : Public となります。 Webサーバーの内部など、ある程度アクセス制限のされた状態で管理されているが、SPAのソースコードやモバイルアプリのバイナリの解析とかによって取得しうるみたいなのは直感的かと思いますが、これだけだといろいろ迷う人がいるらしい、とい
-
JWT 認証のメリットとセキュリティトレードオフの私感 - ..たれろぐ..
2020/5/9追記: 考えた結果、Authorization Bearer ヘッダを使った正規のJWTの場合、同一ドメイン下で読み込む全 JavaScript が信用できる場合でないとブラウザ上で安全にトークンを保持できないのでブラウザからのAPIアクセス時の認証用には使うべきではないというところに着陸しました。ブラウザからのアクセスでは http only cookie にトークンを入れ、 CSRF 対策も忘れずにというこれまで通りの定石が手堅いように思います。 JWTを使うのはトークンの安全な保管ができる非ブラウザなネイティブクライアントからのAPIアクセス時に限った方がよさそうです。 APIサーバ側ではアクセス元に合わせて認証方法を使い分ける両対応が要求されるので手間は増えますが手抜きできる場所でもないので仕方なしと。 React(SPA)での認証についてまとめ - エンジニアの本
-
Refresh Token/リフレッシュトークン： どのような場合に使用し、どのように JWT と相互作用するか
本書では OAuth2 で定義されたRefresh Tokenの概念について学びます。また、Refresh Tokenと他のトークンタイプを比較して、その理由と方法を学びます。さらに、簡単な例を使ってRefresh Tokenの使い方について説明します。それでは、始めましょう！ 更新： 本書を書いた時点では、Auth0 は OpenID Connect 認証を取得していませんでした。本書では access token のような用語の一部は本仕様に準拠しませんが、 OAuth2 仕様には準拠しています。OpenID Connect は access token （Authorization Server[認証サーバー]の API へのアクセスに使用）および id token （リソース サーバーに対するクライアント認証に使用）を明確に区別します。 はじめに先進的な認証および/または認可ソリュ
-
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でサーバ
-
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: 都元、日頃のお
-
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
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 過去三年間、技術者ではない方々に OAuth（オーオース）の説明を繰り返してきました※1,※2。その結果、OAuth をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。Authlete アカウント登録はこちら！ ※2：そして２回目の
-
OAuth 1.0 のほうが OAuth 2.0 より安全なの？ - Qiita
以降、OAuth 1.0 は RFC 5849 を指すものとします。 2. 実際のところはどうなのか？ では「実際のところはどうなのか？」というのは、一次ソースを見ないと正確には分からないので、RFC 5849 を改めて読み直してみました。 分かったことは、私の解釈が間違えていなければ、OAuth 1.0 のセキュリティーは「クライアントアプリケーションに埋め込まれている秘密鍵 ※1 は盗み取られない」という前提に立っているということです。しかしながら、この前提はナイーブです。 ※1: ここで秘密鍵 (secret key) とは、シグネチャーの計算に HMAC-SHA1 を使うのであれば共有鍵 (shared key)、RSA-SHA1 を使うのであればプライベート鍵 (private key) を指します。 OAuth 2.0 (RFC 6749) では、このようなナイーブな前提に立つ
-
ついでに認証周りを理解してGoogle AppsのSAMLでAWSへログインを設定してみる - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに背景的なこと 結構前からですが、クラウドサービスを多く使ってシステムを作る機会が多くなりました。 当然一つのクラウドサービスだけではないので複数使ったりします メールや資料の共有とかも、もはやGoogle Apps For Workで完結します そういった流れの中でID,PW管理が非常に煩雑になり、且つ結構重要なセキュリティ項目になってたりします （AWSのID,PWとか外に出たらヤバイですよね） このクラウドサービスを当たり前に使うようになったこのご時世に、セキュアに効率的にアカウント管理をしようってなって色々調べたメモ的なま
-
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトー
-
rails 4 対応の認可の gem - @znz blog
rails 4 に対応している認可のライブラリとして cancan からの移行先候補を選ぶために the_role と pundit という gem を試してみました。 cancan からの移行 認証は rails 4 でも devise を使い続ければ良さそうな感じなのですが、 認可の方は cancan の rails 4 対応がいまいちで Ready for Rails 4? でも not ready のままで issues も溜まっていることもあり、 rails 4 では他の gem への移行を検討していました。 移行先候補 移行先候補として、まず最初に試したのは the_role という gem でした。 後述しますが、これは最初から組み込むなら良さそうなのですが、 今回はちょっと目的にあわなかったので諦めました。 次に試したのは pundit という gem で、 これは Sim
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました