JWT・Cookieそれぞれの認証方式のメリデメ比較 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? JWTとは JSON Web Tokenの略。ジョットと読むらしい。 ざっくりいうとJsonに電子署名を加え、URL-Safeな文字列にしたTokenのこと 正確にいうと、電子署名を使用する方式はJWS（JSON Web Signature）と呼ばれ、別途暗号化を使用するJWE（JSON Web Encryption）も存在する。よく見かける説明はJWS方式のほう。 JWS方式の場合、電子署名であり暗号化ではないため、中身を見ることは可能。但し改ざんはできない、という仕組み。 実際のユースケースで言うと、サーバ側で認証情報が入ったJso
Firebase AuthなどJavaScriptでAPIセッション用のトークンを得ることについて - Qiita
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう （※ こちらの参照記事の内容自体に不備があるとか甘いとか指摘するものではないんですが、勝手に枕として使わせてもらいます） 上記記事は、Firebase Authenticationが提供するJavaScript APIを使ってJWTのトークンを取得し、自前のサーバにHTTPのヘッダで送りつけて検証をさせることで、認証の仕組みをセキュアかつかんたんに実現しよう、という内容です。 このようにJavaScriptのAPIでトークンを発行して自前バックエンドのAPI認証につかう方法はAuth0のSDKなどでも行われていますので、IDaaSをつかってSPAを開発する場合には一般的なのかもしれません。 話は変わりますが、SPAの開発に携わっている方は「localStorageにはセッション用のトー
社内で毎週公開してるセキュリティコンテンツ3ヶ月分を公開します【2020年4月〜7月】 - Qiita
Slackでも昔はポップアップや警告ダイアログが出ないで攻撃のリンクに飛ばされていた時期があり、当初Slack側は「ワークスペース内のメンバーの対立が前提」と延べ、脆弱性を認めていなかったが、外部からのメールの注入などで起こりうる可能性があるとして、脆弱性と判断した背景があります。 やりとりはこちら https://hackerone.com/reports/481472 我々は、日々開発していく中で、URLを扱うことはとても多いです。 それこそ、**<サービス名>**などでも今後、URLに自由な表示文字を設定できるようになる仕様が出てくるかもしれないです。 新しいサービスを作る時に要件が上がってくるかもしれないです。 そうなった時に、今回のような脆弱性のパターンを思い出してもらい、回避することで安全なサービスを作っていきましょう。 二要素認証（2020/05/14） みなさん、**二段階
Auth TokenをlocalStorageに入れようが、cookieに入れようがどっちもXSS危険性には無防備（同ドメイン内なら ...） - Qiita
tokenを保存する場所 localStorage cookie cookie (http only) メモリ内 (変数) よく言われるのが JWT tokenをlocalStorageに入れるべきではない ということ。 理由としてはJavascriptで簡単に読めてしまうので、XSSがあった場合意図しないスクリプトを動かされてしまい、結果としてtokenが盗まれるというもの。 対応策として cookie (http only) を色んな所で推奨してる。 https://techracho.bpsinc.jp/hachi8833/2019_10_09/80851 http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/ http://cryto.net/~joepie91/blog/2016/06/19/
SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜 - Qiita
SPAのログイン周りについて、「これがベストプラクティスだ！」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです！特に「おすすめ度：○」と記載しているものに対しての批判をどしどしお待ちしております！ この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外ではCSRFを考慮しなくてよい、 という前提で話を進めます。 また、XSSに関しては常に対策は必要なのですが（フレームワーク側が自動的にしてくれる部分もある）、認証周りに関係すること以
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
