OCHaCafe Season4 #4の資料です. デモのソースコード等は

Communeをご利用いただいている企業様限定のコミュニティです。 コミュニティの運営法やCommuneの活用術について、役立つ情報交換や相談を行うことができます!
シングルサインオンは、システム内のユーザーを認証し、そのユーザーが認証されたことをZendeskに通知する機構です。JSON Webトークン(JWT)でシングルサインオンを使用する場合、サインイン時にユーザーがアイデンティティプロバイダによって自動的に検証されます。認証済みであると通知されたユーザーは、サインイン資格情報の入力を求められることなく、Zendeskにアクセスできるようになります。 Zendesk管理者としての役割は、SSOオプションを有効にすることです。この記事では、チームメンバー(管理者と、ライトエージェントと閲覧担当を含むエージェント)、エンドユーザー、またはその両方の認証に使用できる、複数のJWTシングルサインオン設定を有効にする方法について説明します。 シングルサインオンの基幹部分は、Zendeskがシステムから取得したサインインリクエストを信頼できるようにするセキュ
ユーザー認証周りのAPIを作っていたのですが、その中でJWTの仕組みを使いました。使い方はシンプルで分かりやすく比較的簡単にセキュリティ向上を見込めると感じたのですが、日本語の資料がまだ少なく敷居が高い印象でした。使ってみたら予想以上に便利だったのでメモを共有します。 間違いなどありましたら指摘お願いします。 JWT概要 JWTは「Json Web Token」の略 JWTはjsonをトークン化する仕組み 改ざん出来ないjsonと思ってもらえればOK Signed JWT JWTがサポートしている署名アルゴリズム HMAC : 共通鍵方式 RSA : 公開鍵方式 ECDSA : 楕円曲線暗号(あまり使われ得ていない) 運用 秘密鍵と公開鍵を作っておく 送りたいデータを秘密鍵でエンコードし、レスポンスとして返す 帰ってきたJWTをセッションに保存 受信側は公開鍵を使ってトークンをデコードし、
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
SPA(Vue + RailsAPI)で何とかログイン認証機能 + CSRF対策を実装したので、ブログにメモしておきます。 実装の概要 使用した技術たち JWT(JsonWebToken) アクセストークン、リフレッシュトークンって? WebStorage JWTSession 遷移の概要(より正確な内容は要Gem参照) トークンストアの設定 バックエンド側の仕事 Signinコントローラー フロントエンド側の仕事 axiosのインスタンスの作成 main.jsでインスタンスの読み込み インスタンスの使用方法 ただ、ブラウザによって上手く動作しないものが… 3rd party cookiesとは? 余談 実装の概要 今回は、JWT + (WebStorage + Cookie)を使って実装しました。(後に用語説明します) WebStorageとJWTによるセッションの管理(ログイン状態の管
SPAのログイン周りについて、「これがベストプラクティスだ!」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです!特に「おすすめ度:○」と記載しているものに対しての批判をどしどしお待ちしております! この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外ではCSRFを考慮しなくてよい、 という前提で話を進めます。 また、XSSに関しては常に対策は必要なのですが(フレームワーク側が自動的にしてくれる部分もある)、認証周りに関係すること以
Send feedback Authenticate with a backend server Stay organized with collections Save and categorize content based on your preferences. If you use Google Sign-In with an app or site that communicates with a backend server, you might need to identify the currently signed-in user on the server. To do so securely, after a user successfully signs in, send the user's ID token to your server using HTTPS
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 ユーザープール JSON ウェブトークン (JWT) の理解 トークンはユーザーを認証し、リソースへのアクセス権を付与します。トークンのクレームはユーザーに関する情報です。ID トークンには、ユーザー名、苗字、E メールアドレスなど、身元に関するクレームが含まれています。アクセストークンには、認証されたユーザーがサードパーティー API、Amazon Cognito ユーザーのセルフサービス API オペレーション、および userInfo エンドポイント にアクセスできる scope のようなクレームが含まれています。アクセストークンと ID トークンの両方に、ユーザープール内でのユーザーのグループメンバーシップを示す cognito:groups クレームが含ま
TL;DR JWTはCookieを使った認証の代わりに使うのはきつい。 コードを静的にホスティングしているSPAの話。 JWTの有効期間を長くすれば危険で、短くすればUXが犠牲になるというトレードオフがある。 AWS AmplifyはlocalStorageにJWTを保存 悪意のあるThird partyライブラリが混ざっていたらJWTを抜かれる。 yarn.lockが依存している全ライブラリを監査することはつらい。 Auth0ではiFrameを活用してメモリ上にJWTを格納できる Auth0いいね😍 まくら Youtubeが大好きなHiCustomerの小田です。ちょっと遅いですが年明け最初のエントリーです。今年もテックブログをよろしくお願いします😎ちなみに、気分がいいので年明けに観ていたYoutubeのエントリーの中で一番おもしろかった動画を紹介します。世界中で有名な「Auld L
世の中にはJWT(JOSE/JWS/JWE)でセッション管理をしてはいけないという記事が2017年から山ほどあるのに、なぜかJWTでセッション管理をしようとする人がいる。翻訳記事だったり暗号の説明が長すぎたりして、JWTをセッションに使ってしまうような人の心に刺さってないんじゃないだろうか。 前提 JWTでセッション管理というのは、暗号化したトークンをブラウザのCookieに持たせて、サーバー側ではトークンを復号化してユーザー判定などのセッション管理を行うことである。サーバー側で[sessionId: userId]のペアを管理する必要がないのでステートレスに扱えてスケールしやすいというメリットがある。 問題 すごく便利な図があったのでまずこれを読んで欲しい。セッション方式の策定/設計をする職位の人ならすんなり読めると思う。 co3k.orgより引用 1 左から4番目Local Stora
注: 本稿は元はJSON Web Tokens(JWT)について書いたものですが、JWTはJavascript Object Signing and Encryption(JOSE)のサブセットであるため、以下の批評はどちらかというとJOSE全体に焦点を当てています。 もし既にJavascript Object Signing and Encryption(JOSE)を実装することを決めているなら、それがJSON Web Tokens、JSON Web Encryption(JWE)、JSON Web Signatures(JWS)のいずれであっても、その決断に疑問を持つべきです。間違いを犯そうとしている可能性があります。 この投稿に書いたことはすべて、RFC 7519、RFC 7515、そしてRFC 7516に則っています。将来、新規のRFCでは以下に挙げるような欠陥はなくなっている可能
GrapeTokenAuth is a token authentication solution for grape. It is compatible with ng-token-auth (for angular) and j-toker (for jQuery), and is meant as a grape (rather than rails) version of devise_token_auth. As such, this project is built entirely upon grape and warden and avoids the need for rails. However, it has built in compatibility for devise if you are looking to mount a grape app within
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く