DevelopersIO 2021 Decadeで「全員がOAuth 2.0を理解しているチームの作り方」というテーマで話させていただきました。 DevelopersIO 2021 Decade で「全員がOAuth 2.0を理解しているチームの作り方」というテーマで話させていただきました。 スライド 話した内容 なぜ人類は OAuth 2.0 に入門し続けるのか なぜ OAuth 2.0 をチームに根付かせたいのか 開発フローとしてコードレビューがある 仕様がわからないと、レビューができない コードと仕様のすり合わせのために仕様が分かる必要がある OAuth 2.0 はまあまあややこしい OAuth 2.0 では登場人物が4人いて、それぞれがいろんなやりとりをします。 それぞれのやりとりにパラメーターがあるので、誰が誰にどういう値をどうして送る、みたいなところまで考えるとまあまあやや
この記事では、サーバーサイドレンダリングする Universal モードの Nuxt.js フロントアプリと、それとは異なるサブドメインで運用される Web API という構成でクッキー認証とCORSを実現する方法を紹介します。 Nuxt でアプリケーションを構築する場合、サーバーサイド（というかデータ取得部分）は Web API になるでしょう。そして Web API での認証といえば JWT を用いたステートレスなトークン認証が一般的かと思います。しかし JWT を LocalStorage に格納する実装は脆弱なアンチパターンであると主張する記事や以下参考リンクの記事を読み、フロントエンド + Web API な構成でもクッキーで認証を行い CORS でクロスサイトなアクセスを防ぐ実装パターンを考えてみました。 今回の実装パターンは以下の記事を参考にしました。 独自ヘッダをチェックす
【変更履歴 2018年2月15日】当初の記事タイトルは「いまなぜHTTPS化なのか？ 技術者が知っておきたいSEOよりずっと大切なこと ― TLSの歴史と技術背景」でしたが、現行のものに変更しました。現在GoogleではWebサイトのHTTPS対応と検索結果の関係を強調しておらず、本記事の趣旨の一つにも本来は独立した問題であるSEOとHTTPS化を関連付けるという根強い誤解を解くことがありますが、当初のタイトルではかえってSEOとHTTPSを関連付けて読まれるおそれがあり、また同様の指摘もいただいたことから変更いたしました。 HTTPとHTTPSは、共にTCP通信上で動作します。したがって、いずれもTCPハンドシェイクで通信を開始します。 HTTP通信の場合には、このTCPハンドシェイク直後に、HTTPリクエストとレスポンスのやり取りが始まります。このHTTPのやり取りは平文通信であり、途
Google、Mozilla、マイクロソフトが「WebAuthn」の実装を開始。これによって「FIDO2」の普及が期待され、Webブラウザから指紋認証や顔認証などで簡単にWebサイトへのログインや支払いの承認といった操作が実現されそうだ。 多くのWebアプリケーションは、ユーザーの認証にユーザー名とパスワードの組み合わせを用いています。 しかしユーザー名とパスワードの組合わせを用いる方法にはさまざまな問題が指摘されています。身近なところでは、安全なパスワードを生成することの手間や、安全性を高めるためにパスワードの使い回しを避けようとした結果発生する多数のパスワードを管理することの手間などがあげられます。 そしてこうしたパスワードの不便さが結果としてパスワードの使い回しを引き起こし、いずれかのサイトで万が一パスワードが流出した場合にはそれを基にしたリスト型攻撃が有効になってしまう、などの状況
よく訓練されたアップル信者、都元です。「認証 認可」でググると保育園の話が山程出て来ます。が、今日は保育園の話ではありません。そちらを期待した方はごめんなさい。こちらからお帰りください。 さて、先日のDevelopers.IO 2016において、マイクロWebアプリケーションというテーマでお話させて頂きました。一言で言うと OAuth 2.0 と OpenID Connect 1.0 のお話だったのですが、これらを理解するにあたっては「認証」と「認可」をはっきりと別のものとしてクッキリと認識する必要があります。 まず、ざっくりとした理解 認証と認可は密接に絡み合っている一方で全く別の概念です。正直、理解は簡単ではないと思います。 まず「認証」は英語では Authentication と言います。長いので略して AuthN と書いたりすることもあります。意味としては 通信の相手が誰（何）であ
各種APIをクライアントプログラムから利用するためには、OAuth 2.0 Protocolにより規定された認可を行うことが求められます。この手順により、クライアントプログラムがどのようなAPIアクセスを行い、そしてどのような情報が参照または更新されるのか（これをスコープと呼びます）がユーザに提示されます。ユーザの認証、および提示されたスコープについてユーザが同意した場合にのみ、クライアントプログラムはAPIにアクセスするための情報（トークンなど）を得ることができます。 [RFC 6749 - The OAuth 2.0 Authorization Framework] http://tools.ietf.org/html/rfc6749 [RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage] http:
Node.jsでのセッションの使い方の勉強です． jadeでやってるサンプルが多いですが，jadeはイマイチ直感的に書けない(慣れない)のでテンプレートエンジンはejsを使います． 勉強中なので自分が理解出来るように解説してみます． 参考: Expressでログイン機能を作る - uchida75cmの日記 参考: Node.js + Express でログイン認証機能を実装する - Devlog バージョン node v0.10.23 express 3.4.8 npm 1.3.17 MongoDB shell version: 2.4.8 まずはプロジェクト作成 $ express -e login $ cd login $ npm install $ node app.js とりあえずブラウザからhttp://lobalhost:3000にアクセスして確認してみましょう．エラーが無く
@novです。 個人的に最近OAuth 2.0よりJWT (というかJWS) を利用するシーンが多く、毎回同じ説明するのもめんどくさいのでブログにまとめるかと思い、どうせならOAuth.jpに書くかということで、こんな記事を書いております。 （そろそろJWTとJWSは、OpenID Foundation Japanの翻訳WGで翻訳するべき？） JSON Web Token (JWT) とは、JSONをトークン化する仕組み。 元々はJSONデータにSignatureをつけたりEncryptionする仕組みとして考えられたものの、Signature部分がJSON Web Signatue (JWS)、Encryption部分がJSON Web Encryption (JWE) という仕様に分割された。 それぞれ2012年10月26日現在の最新仕様はこちら。 （JWTとJWSは既にだいぶ仕様が固
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
