認可と認証技術についてのスライドを書きました - ngzmのブログ
認可と認証技術 OAuth 1.0、OAuth 2.0 および OpenID Connect に関するスライドをアップしました。 アプリ開発で知っておきたい認証技術 - OAuth 1.0 + OAuth 2.0 + OpenID Connect - from Naoki Nagazumi www.slideshare.net 開発している Web アプリで、OAuth 1.0 や OAuth 2.0 および OpenID Connect の認可と認証技術を組み込んだ時に、あれこれ調査して知り得た技術をまとめたものです。 130ページくらいの力作です！ぜひご覧ください。 デモ これのデモはこちらにあります AuthsDemo デモのソースコードはこちらです。 GitHub - ngzm/auths-demo: This is a demo program with using OAuth
JWT(JSON Web Token)を使った認証を試みる
Oauth2やOpenID Connectなどすでに導入されているJWT(JSON Web Token)。 今後IoTとかを考えると認証手法としては結構有効な認証方法だということで、改めて眺めてみた。 JSON Web TokenJSON Web Token(JWT) jot(ジョット)と発音する。 JSONを電子署名したurl-safe(URLで使用できない文字が含まれる)なclaimのことを指す。rfc7519 また同じような言葉もあるので一旦整理する。 JWS は署名したもの JWE はEncryptしたもの 一般的にJWTというとJWSのことをいう。 電子署名(公開鍵+秘密鍵方式)をしているため、データの読み出し、書き込みができる。 しかし、その内容の改竄はチェックできる。 JSONの内容を秘匿化するわけではないので、内容は誰でも見ることはできるという点は注意が必要。 jwt.io
JSON Web Token の効用 - Qiita
Note: JWT の仕様やそもそも論の話は触れません。どう使うか、何が出来るかしか書いていません。 JSON Web Token? JSON Web Token とは、ざっくりいって署名の出来る JSON を含んだ URL Safe なトークンです。 署名とは、署名時に使った鍵を用いて、JSON が改ざんされていないかをチェック出来るようにすることです。 URL Safe とは、文字通り、URL に含めることの出来ない文字を含まないことです。 これだけだとよくわかりませんが、触り心地としては次のような性質があります。 発行者だけが、鍵を使ってトークンが正しいことを検証出来る。 暗号化ではないので、JSON の中身は誰でも見られる。 仕様的には、暗号化のオプションもあります。 しかしながら、JSON の変更は出来ない。（改ざんをすると、検証時に失敗するので。） 全体的には、なんか変更できな
俺のSMS認証がこんなに非推奨なわけがない
NISTは本当にSMS認証を非推奨としたのか。真実を追って我々はジャングルに飛び込んでいった... 8/1 13:30: 構成を一部変更・追記
マイクロサービスで必要になるかなぁって思って僕がOAuth2とOpenID Connectをなんとなく分かるようになるまでの物語 - Mitsuyuki.Shiiba
プライベートの勉強は気が向くままにふらふらと。梅田の地下街を歩いてる感じで！（←つまり迷ってる） 元々は、Pivotal Japanさんの、この「今日から君もヒーローだ！」的なタイトルに惹かれてJava(Spring Cloud)でマイクロサービス作るぞーって進めてみたのであった。が、早速その2の「認可サーバーを立ち上げよう！」で「あー、これ知らない。分かんない。もう寝たい。」となってしまったのだった。 そんな僕が「なんとなく分かった！」になるまでの物語。・・・になるはず（ここを書いてる今はまだ分かってない）。 たぶん1ヶ月したら何を読んだか忘れてると思うので記録しとくことにした。 github.com ゴール OAuth 2.0って聞いたことあるけど、よく知らない。この辺、マイクロサービスの認証・認可部分で必要そうだなーって思うので、OpenID 2.0とOpenID Connectも含
PAM について考える。pam_ssh.so とか。 - daily dayflower
以下の文書は様々なセキュリティリスクについてアセスメントしてないんで参考程度にとどめておいてください。 PAM の auth の流れ ステート図については⇒【http://corvus.kek.jp/~manabe/pcf/pam.htm】を参照。 書式についてはいっぱいころがっているので省略。で，コントロールフラグについて。 コントロールフラグは PAM モジュールが「成功」「失敗」のステータスを返した時にどのような処理を行なうかを指定します。基本は required, requisite, sufficient, optional の四種類です。 required (必要条件) そのモジュールから成功のステータスが返る事を要求します。required となっているモジュールが失敗のステータスを返すと他のモジュールの処理の結果にかかわらずログインに失敗します。ただし、処理は打ち切られる事
OpenSSH の ChallengeResponseAuthentication と PasswordAuthentication
OpenSSH の ChallengeResponseAuthentication と PasswordAuthentication 2014/6/14 2014/11/22 CentOS, Linux, サーバ管理, セキュリティ “ChallengeResponseAuthentication” で検索してこのブログに辿り着く人が多いのですが、ChallengeResponseAuthentication についてはちゃんと書いてないし、PasswordAuthentication との違いは昔から気になっていたので、調べてみることにしました。 調べたのは CentOS 6.5 の openssh-5.3p1-94.el6 です。これ以降のバージョンの OpenSSH でもおそらく同じだと思います。 結論から言うと、 * PasswordAuthentication: RFC 4252
ユーザー認証の手抜き - 方向
Webアプリ作っているといろんな局面でユーザー認証が必要になる局面がある。まじめにつくると果てしなく面倒だし、適当につくるとセキュリティ上問題になるので、要件に応じて適切に手抜きする必要がある。 適当なやつからしっかりしたやつまでなんとなくソートしていくとこんなかんじだと思う。 認証なし IPで弾く Basic認証（ソースコード、設定ファイルにパスワードベタ書き） Basic認証（DBにUserテーブルをつくってパスワードを保存。追加はcliとかで手動） login/logout画面作成。cookieなりmemcacheなりにセッションを保存 webからユーザーを追加できるように password変更機能 OAuth OpenID mailを送ってリンクをクリックさせてメールアドレスの所有確認 メールアドレス変更機能 メールを使ってのパスワードリセット機能 OAuthで作ったアプリへの後か
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
