タグ

qiitaとjson-web-tokenに関するnabinnoのブックマーク (7)

  • JWTの概要とRubyにおける使い方のメモ - Qiita

    ユーザー認証周りのAPIを作っていたのですが、その中でJWTの仕組みを使いました。使い方はシンプルで分かりやすく比較的簡単にセキュリティ向上を見込めると感じたのですが、日語の資料がまだ少なく敷居が高い印象でした。使ってみたら予想以上に便利だったのでメモを共有します。 間違いなどありましたら指摘お願いします。 JWT概要 JWTは「Json Web Token」の略 JWTはjsonをトークン化する仕組み 改ざん出来ないjsonと思ってもらえればOK Signed JWT JWTがサポートしている署名アルゴリズム HMAC : 共通鍵方式 RSA : 公開鍵方式 ECDSA : 楕円曲線暗号(あまり使われ得ていない) 運用 秘密鍵と公開鍵を作っておく 送りたいデータを秘密鍵でエンコードし、レスポンスとして返す 帰ってきたJWTをセッションに保存 受信側は公開鍵を使ってトークンをデコードし、

    JWTの概要とRubyにおける使い方のメモ - Qiita
  • 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として使用する。 仕組みについては調べればたくさん出てくるのでそちらを参照したほうが良いかと思います。 この記事では

    JWT・Cookieそれぞれの認証方式のメリデメ比較 - Qiita
  • SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち?〜 - Qiita

    SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち?〜JavaScriptRailsJWT認証React SPAのログイン周りについて、「これがベストプラクティスだ!」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです!特に「おすすめ度:○」と記載しているものに対しての批判をどしどしお待ちしております! この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外では

    SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち?〜 - Qiita
  • JWTでセッション管理してはいけない - Qiita

    世の中にはJWT(JOSE/JWS/JWE)でセッション管理をしてはいけないという記事が2017年から山ほどあるのに、なぜかJWTでセッション管理をしようとする人がいる。翻訳記事だったり暗号の説明が長すぎたりして、JWTをセッションに使ってしまうような人の心に刺さってないんじゃないだろうか。 前提 JWTでセッション管理というのは、暗号化したトークンをブラウザのCookieに持たせて、サーバー側ではトークンを復号化してユーザー判定などのセッション管理を行うことである。サーバー側で[sessionId: userId]のペアを管理する必要がないのでステートレスに扱えてスケールしやすいというメリットがある。 問題 すごく便利な図があったのでまずこれを読んで欲しい。セッション方式の策定/設計をする職位の人ならすんなり読めると思う。 co3k.orgより引用 1 左から4番目Local Stora

    JWTでセッション管理してはいけない - Qiita
  • Golang(ECHO+GORM)でJWTとGraphQLの環境を構築 - Qiita

    package main import ( "github.com/labstack/echo" "github.com/labstack/echo/middleware" "./handler" ) func main() { e := echo.New() e.Use(middleware.Logger()) e.Use(middleware.Recover()) e.GET("/hello", handler.Hello()) e.POST("/login", handler.Login()) r := e.Group("/restricted") r.Use(middleware.JWT([]byte("secret"))) r.POST("", handler.Restricted()) e.Start(":3000") } package handler import ( "n

    Golang(ECHO+GORM)でJWTとGraphQLの環境を構築 - Qiita
  • KONGことはじめ - Qiita

    KONGとは 公式読めってのはおいといて 噛み砕いて説明すると マイクロサービスを構築する時のAPI Gatewayとなるもの リバプロの役割をしてリクエストを各APIに振り分けるよ pluginで認証や流量制限、ログ取りもできるよ kong体もクラスタ化できるし、APIもアグリゲーションできるよ API GatewayみたいのがないとたくさんAPIサービス作るとわけわかんなくなっちゃうよ 実際はnginxの拡張モジュールのようなものでAPIを経由してnginxの設定に反映してくれる感じ つまり色々な言語で実装されたAPIサービスの総合窓口。 KONG配下にAPIサービス群を置いてあとはfrontendでもcurlでも好きに叩けば? くらいの構成にできそう KONG以外だとcloud系でAWS API GatewayとかAzureのAPI ManagementとかGoogle Cloud

    KONGことはじめ - Qiita
  • JSON Web Token の効用 - Qiita

    Note: JWT の仕様やそもそも論の話は触れません。どう使うか、何が出来るかしか書いていません。 JSON Web Token? JSON Web Token とは、ざっくりいって署名の出来る JSON を含んだ URL Safe なトークンです。 署名とは、署名時に使った鍵を用いて、JSON が改ざんされていないかをチェック出来るようにすることです。 URL Safe とは、文字通り、URL に含めることの出来ない文字を含まないことです。 これだけだとよくわかりませんが、触り心地としては次のような性質があります。 発行者だけが、鍵を使ってトークンが正しいことを検証出来る。 暗号化ではないので、JSON の中身は誰でも見られる。 仕様的には、暗号化のオプションもあります。 しかしながら、JSON の変更は出来ない。(改ざんをすると、検証時に失敗するので。) 全体的には、なんか変更できな

    JSON Web Token の効用 - Qiita
  • 1