よく訓練されたアップル信者、都元です。「認証 認可」でググると保育園の話が山程出て来ます。が、今日は保育園の話ではありません。そちらを期待した方はごめんなさい。こちらからお帰りください。 さて、先日のDevelopers.IO 2016において、マイクロWebアプリケーションというテーマでお話させて頂きました。一言で言うと OAuth 2.0 と OpenID Connect 1.0 のお話だったのですが、これらを理解するにあたっては「認証」と「認可」をはっきりと別のものとしてクッキリと認識する必要があります。 まず、ざっくりとした理解 認証と認可は密接に絡み合っている一方で全く別の概念です。正直、理解は簡単ではないと思います。 まず「認証」は英語では Authentication と言います。長いので略して AuthN と書いたりすることもあります。意味としては 通信の相手が誰（何）であ
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 前回は、APIをエッジで処理する有効性について説明した。第2回の本稿では、APIの認証と認可をエッジでどのようにスケールさせるかを説明したい。 APIのタイプには、パブリックとプライベートがある。パブリックなものは、誰でもAPIを呼び出すことができ、大概は一定期間キャッシュできるため、コンテンツ配信ネットワーク（CDN）のような仕組みは非常に有効だ。例えば、検索結果を返すAPIは、バックエンドのデータベース情報が変わらなければ常に同じ結果を返すので、エッジでキャッシュできればエンドユーザーの操作性はかなり良くなる。また、毎回オリジンサーバにリクエストが届かなくなるので、クラウド基盤のコンピュータリソースもコスト削減できる。 問題なのは、
(ふと描き忘れたなというところを追記してます) どこで何を話したのか builderscon tokyo 2018 にてお話しして来ました。 builderscon.io 資料もアップロード済みです。 builderscon tokyo 2018 のスライド公開しました。 "パスワードレスなユーザー認証時代を迎えるためにサービス開発者がしなければならないこと" https://t.co/5NaikVcyBi #builderscon #buildersconC— 👹秋田の猫🐱 (@ritou) September 7, 2018 内容は以下について緩く話して来ました。 パスワード認証 : そもそも人類には無理そう あるある実装 : パスワード認証 + リカバリー、最近多要素認証。ソーシャルログインはパスワードとセットになってる。 WebAuthn : 細かい生体認証とかを頑張るのは A
Google、Mozilla、マイクロソフトが「WebAuthn」の実装を開始。これによって「FIDO2」の普及が期待され、Webブラウザから指紋認証や顔認証などで簡単にWebサイトへのログインや支払いの承認といった操作が実現されそうだ。 多くのWebアプリケーションは、ユーザーの認証にユーザー名とパスワードの組み合わせを用いています。 しかしユーザー名とパスワードの組合わせを用いる方法にはさまざまな問題が指摘されています。身近なところでは、安全なパスワードを生成することの手間や、安全性を高めるためにパスワードの使い回しを避けようとした結果発生する多数のパスワードを管理することの手間などがあげられます。 そしてこうしたパスワードの不便さが結果としてパスワードの使い回しを引き起こし、いずれかのサイトで万が一パスワードが流出した場合にはそれを基にしたリスト型攻撃が有効になってしまう、などの状況
月刊 App Engine SDK の6月号は1.3.4。Google I/Oではfor business とか、VMware との協業とか、mapper APIとかchannel APIとかもっと面白い話しがあったようだけど、SDK 1.3.4の最大の売りは、OAuth対応とOpenID対応の二つのユーザ認証機構。ここではOpenIDでの認証のしかたを書いてみる。 リクエストを送るには3rd partyのライブラリかなんかが必要なんだろうと思って、いろいろ調べたり試したりして、数時間を無駄にしたのだけど結局わからず、twitterでつぶやいたら @shin1ogawa さんに1分後に教えていただいた。 ありがとうございました@shin1ogawaさん！そして、おそるべしtwitter。。。 OpenID の動作 OpenID はFederated Identity と呼ばれるものの一つで
※前置き長いです。本題はここから。 9/6 ごろから 9/9 にかけて、TwitMgr (閉鎖済) と Splitwit (閉鎖済) の OAuth 認証が正しく動作しなくなってしまっていました。 これらは、JavaScript で Twitter API を扱うライブラリとして、TwitAPI.js を使っており、それがうまく動作していなかったのです。で、原因を追ったところ、JavaScript 側ではなく、OAuth 認証を肩代わりするプロキシサーバである taj-proxy 側に問題があることがわかったので、今回はそれを直したときの話です。 そもそも、taj-proxy は、開発当初 GAE/j 上でうまく Twitter OAuth 認証を扱えるライブラリがなかった (と思っていた) ため、OAuth 認証部分をすべて独自実装してました。Twitter 側の何らかの実装の変更により
タイプパッドから銅メダルを奪い取った後、タンブラはついにOAuthを第三者のクライアント用のAPI（アプリケーション・プログラミング・インターフェースの略）に導入する決断を下したようだ。 セキュリティを強化し、そして、第三者アプリの回復機能を増すために、私たちはOAuthのサポートの初期テストをタンブラのAPIで開始しました。 私たちはツイッターを手本にして、OAuth 1.0aをサポートし、モバイルアプリおよびネイティブアプリ等、理に適う場合、要求に応じて最適なxAuthを採用する形を取りました。 APIの既存の認証メソッドは現時点ではサポートされていますが、開発者の方々には極力OAuthに移行するよう勧めています。（タンブラスタッフブログ） ギークではない人のために簡単に説明しておこう。OAuthは基本的には開発者にパスワードを知らせることなく第三者アプリを介してタンブラにログインする
消えちゃったよ。。 はてなダイアリー素人なので書いたのをなんか間違って消してしまった。。orz 後半だけクリップボードに残ってた。orz なので、書き直した前半は適当。 acts_as_authenticatedをインストール $ ruby script/plugin discover $ ruby script/plugin install acts_as_authenticated ジェネってmigration $ ./script/generate authenticated user account $ rake db:migrate その他の機能はあとで メール認証だの、アクティベーションだのはまた今度。 ログインが必要なコントローラは before_filter :login_requiredで認証箇所のコントロール class HogeController < Applica
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
