Developers.IO 2017セッション「基礎からの OAuth 2.0」でお話してきました #cmdevio2017 | DevelopersIO
よく訓練されたアップル信者、都元です。クラスメソッドが運営するIT系技術ブログDevelopers.IOのカンファレンスイベントDevelopers.IO 2017にて、セッション「基礎からの OAuth 2.0」を発表しました。本エントリーはそのレポートです。 発表スライド 発表動画 セッション概要 システム開発をする以上、ほとんどの場合「認証と認可」は切っても切れない問題です。マイクロサービスが話題を集め、コンポーネントのWeb API化が急加速を見せる昨今。OAuth 2.0 という仕組みが継続的に注目を集めています。 しかし、いざその仕様を紐解いてみると Authorization code や Implicit 等、簡単には理解できない概念や選択肢が並んでおり、 自分が導入すべきなのはどのような仕組みなのか、判断が難しいのも確かです。 本セッションでは OAuth 2.0 の仕組
SPAでのセッション管理とセキュリティ - Qiita
基本 普通にcookie使えばいいと思います。 loginリクエストもajaxで投げればcookie返ってくるので、何も考えることないかなと。 Cookie 動作イメージは以下の形です。 == サーバ → UA == Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com == UA → サーバ == Cookie: SID=31d4d96e407aad42 (from https://triple-underscore.github.io/RFC6265-ja.html) ブラウザの状態管理のためのもの。 もちろん主要ブラウザはどこも付いてます。 railsでもplayでもとりあえずこれでセッション管理されています。 secure属性があると、httpsのときだけやりとりされます。 HttpOnly属性があると、jsから読
Redis-rails RailsのセッションをRedisで管理
サーバサイドでのセッション管理はセキュリティを向上させたり、通信で無用なCookieを送らない等の意味でメリットがあります。 今回は『redis-store/redis-rails - GitHub』を使う手順のメモです！ 🍣 サーバサイド/クライアントでのセッション管理のPros/Consセッションに関する説明は次のサイトがお勧めです。注意点としては次の2点と考えられます。 セッション管理の要注意点 - Qiita Rails セキュリティガイド | Rails ガイド - セッションの基礎 - Webアプリでは、接続ごとに固有の識別子(セッションID)を割り当て、一時的なidを割り振る - セッションは他のCookieと合わせて通信のたびにやり取りされる - Cookieのサイズは4 KBと厳密に定められている - セッションにおけるセキュリティのリスク - 他人のセッションを取得す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
