[B! JWT] naga_sawaのブックマーク

naga_sawa id:naga_sawa

JWTに関するnaga_sawaのブックマーク (5)

JWT・Cookieそれぞれの認証方式のメリデメ比較 - Qiita
JWTとは JSON Web Tokenの略。ジョットと読むらしい。ざっくりいうとJsonに電子署名を加え、URL-Safeな文字列にしたTokenのこと正確にいうと、電子署名を使用する方式はJWS（JSON Web Signature）と呼ばれ、別途暗号化を使用するJWE（JSON Web Encryption）も存在する。よく見かける説明はJWS方式のほう。 JWS方式の場合、電子署名であり暗号化ではないため、中身を見ることは可能。但し改ざんはできない、という仕組み。実際のユースケースで言うと、サーバ側で認証情報が入ったJsonを加工（電子署名を加える等）し、JWTにしたのち、それを認証Tokenとしてクライアントに渡す。クライアントはそのTokenを認証Tokenとして使用する。仕組みについては調べればたくさん出てくるのでそちらを参照したほうが良いかと思います。この記事では
naga_sawa 2020/05/09
ブラウザアクセスの場合JWTを安全に保管できないので避けるべき/HTTPヘッダを使うJWTでの認証認可はネイティブクライアント用バックエンド用の限定と考えておくのが無難

開発

Web

セキュリティ

JavaScript

JWT
リンク
JWTは使うべきではない　〜 SPAにおける本当にセキュアな認証方式〜 - Qiita
React/Redux/Spring Boot/AWSでSPAを作っているのですが認証の方式をどうするか悩みました。ベストと思われる認証方式をこちらに記載することにしました︵随時更新します︶。 JWTは使うべきじゃないログイン済みであるという事実をサーバーサイドのセッションを使わずに保存しておく場合、ログインした後でJWTなどのトークンをサーバーで生成し、それをクライアントサイドで何らかの形で保存しておく必要がある。なぜなら、ReactおよびReduxのstateで管理してしまうと、ページをリロードされたときにstateがクリアされてしまうから。具体的な保存先はローカルストレージくらいしか無いのだが JWTをローカルストレージに格納するのは危険。なぜなら、ローカルストレージはJavaScriptで簡単に読み込めてしまうから。自ドメイン以外のJavaScriptを読み込
naga_sawa 2020/05/09
APIにブラウザからアクセスする場合、jsを介すと安全にJWTを保持できないので避けるべき/ブラウザからのアクセス時はhttponly cookieに、nativeからのアクセス時はJWTとサーバ側で両対応にすべき

開発

Web

セキュリティ

JWT

JavaScript
リンク
JWT 認証のメリットとセキュリティトレードオフの私感 - ..たれろぐ..
2020/5/9追記: 考えた結果、Authorization Bearer ヘッダを使った正規のJWTの場合、同一ドメイン下で読み込む全 JavaScript が信用できる場合でないとブラウザ上で安全にトークンを保持できないのでブラウザからのAPIアクセス時の認証用には使うべきではないというところに着陸しました。ブラウザからのアクセスでは http only cookie にトークンを入れ、 CSRF 対策も忘れずにというこれまで通りの定石が手堅いように思います。 JWTを使うのはトークンの安全な保管ができる非ブラウザなネイティブクライアントからのAPIアクセス時に限った方がよさそうです。 APIサーバ側ではアクセス元に合わせて認証方法を使い分ける両対応が要求されるので手間は増えますが手抜きできる場所でもないので仕方なしと。 React(SPA)での認証についてまとめ - エンジニアの本
naga_sawa 2018/09/22
セルクマ/正直これで正しいのかもよく分からない/だれかAPI用認証のベストプラクティス的なの教えて…/→ブラウザアクセスではTokenを安全に保管できないので不向きっぽい/定石のhttponly cookieとCSRF防御でええやん？に着地

開発

Web

セキュリティ

JWT

JavaScript
リンク
JWT認証、便利やん？ - ブログ
どうして JWT をセッションに使っちゃうわけ？ - co3k.org　に対して思うことを書く。 (ステートレスな) JWT をセッションに使うことは、セッションIDを用いる伝統的なセッション機構に比べて、あらゆるセキュリティ上のリスクを負うことになります。と大口叩いておいて、それに続く理由がほとんどお粗末な運用によるものなのはどうなのか。最後に、でもそこまでしてステートレスに JWT を使わなくてはいけないか？とまで行っていますが、JWT認証のメリットはその実装のシンプルさとステートレスなことにあります。現実的には実際はDB参照とか必要になったりするんですが、ほとんど改ざん検証だけで済むのは魅力的です。トレードオフでリアルタイムでユーザー無効化ができないことくらいですかね。ライブラリなんて使う必要ないほどシンプルだし、トレードオフさえ許容できればむしろ、なぜこれ以上に複雑な認証
naga_sawa 2018/09/21
XSS脆弱性は論外として/RefreshTokenで拒否できれば大体はカバーできるのかなぁと思ってる/セキュリティ担保の仕組みと根拠わかってないとcookieにしろTokenにしろ何を使ってても危険は危険/駄文 http://d.hatena.ne.jp/naga_sawa/20180921

開発

Web

セキュリティ

JWT
リンク
どうして JWT をセッションに使っちゃうわけ？ - co3k.org
備考 2018/09/21 22:15 追記 2018/09/20 12:10 に公開した「どうして JWT をセッションに使っちゃうわけ？」というタイトルが不適切だとご指摘をいただいています。その意見はもっともだと思いますので、現在、適切となるようにタイトルを調整しています。ご迷惑およびお騒がせをして大変申し訳ございません。本文の表現についても改善の余地は大いにありそうですが、こちらは (すでにご意見を頂戴している関係で、) 主張が変わってしまわないように配慮しつつ慎重に調整させていただくかもしれません。はあああ〜〜〜〜頼むからこちらも忙しいのでこんなエントリを書かせないでほしい (挨拶)。もしくは僕を暇にしてこういうエントリを書かせるためのプログラマーを募集しています (挨拶)。 JWT (JSON Web Token; RFC 7519) を充分なリスクの見積もりをせずセッシ
naga_sawa 2018/09/20
サーバ側でトークン無効扱いできる仕組みを仕込めばrevoke周りはなんとかなるけど分散時に情報共有不要ってメリット潰れる気もする/それするなら従来型のセッショントークン+Redis類でええやんと/決め手はないものか

開発

Web

セキュリティ

JWT
リンク
1