koress.jp: OpenIDの襲来に備えよ！
追記: OpenID対応サービスまとめを作りました。 たぶん、2008年のインターネット（Webサービス)業界はOpenIDによるWebサービスのID体系の統一の荒波に揉まれることになると思う。日本のサービスプロバイダは、OpenIDの襲来に備えるべき。 海の向こうではすでにDigg, Wikipedia, Yahoo, Microsoftなどが導入や支持を発表しているほか、多くの小さなネットサービスはOpenIDに頼ったアーリーアダプタの取り込みに積極的になってる。日本国内ではどうかと言えば、niftyのaboutmeなどを除いて大手のWebサービスは未だ様子を見ている状態。リサーチレベルでは重要性が把握されつつある一方、経営レベルでは「なにそれ」的な状態が多そう。いかん、いかんよ。 2008年、YahooかAmazonかGoogleかわからないけれど、ほぼ間違いなくどこかの日本の大手の
OpenIDが熱狂的に受け入れられる理由 ― ＠IT
2007/04/23 3月15日、米国の全国紙USA Todayの「Tech」セクションの紙面をOpenIDに関する記事が飾った。その記事では、さまざまなインターネットサービスが利用されるようになる中、増加の一方をたどる「IDとパスワード」を記憶する義務からユーザーを解放する新しい技術としてOpenIDが紹介されている。 OpenIDは、URLをIDとして利用する認証プロトコルである。ユーザーはOpenID認証サーバが提供するIDをコンシューマ（OpenIDによる認証に対応したサービスプロバイダのこと）でのログインに利用することができる。コンシューマはOpenIDをもとに認証サーバを発見し、自身で認証する代わりにサーバへ認証を依頼する。ユーザー認証はすべて認証サーバ上で行われるので、ユーザーはOpenIDを1つだけ覚えておけば複数のサービス（コンシューマ）へログインできるようになる。つまり
ケルベロス認証
ポイント ●ケルベロス（Kerberos）認証とは，複数のサーバーと複数のユーザーの認証情報を一元管理するのに適したしくみである。やりとりする通信を暗号化する機能もある ●ケルベロス認証を実装するには，コンポーネント間で時刻同期が必要 ●シングルサインオンとは，1回の認証で複数のサービスを利用できるようにするしくみのこと これまでにネットワーク環境で利用されている認証方式を見てきましたが，今回はケルベロス認証という技術を学びます。ユーザー情報を一元管理し，一度受けた認証情報をほかのサーバーへアクセスするときにも引き継げるようにする仕組みです。社内ネットなどに多数のユーザーとサーバーが存在し，個々のユーザーは同時に複数台のサーバーへアクセスする必要がある時に威力を発揮します。 PPPやRADIUSとは違う 前回までネットワーク環境で利用される認証方式をいくつか紹介してきました。ここで簡単に整
結城浩のはてな日記 - はてな認証API / ためしに作ってみました
はてな認証APIが公開されましたので、ためしてみました。 懸念事項 なおやさんところ経由ではてな認証APIの公開について(開発者さま向け)を読んで感じたこと。 おそらくすぐに「はてな認証APIで○○を作ってみました」的なものが登場するでしょう。おもしろいアプリが登場することを期待。 ただし、一般ユーザにきちんと認識させないと、悪意のある第三者が一般ユーザのパスワードを奪うアプリを作ってしまう危険性があります。たとえば「はてな認証APIを利用しています」と偽って、「ログイン名とパスワードを入力させるフォーム」を見せるアプリが出た場合、ユーザは誤解しないか。 それから…解説した図がほしいです。→認証部分のシーケンス図は結城が描きました(このエントリの下の方で公開しています)。 結城さんちのはてな認証APIテスト 追記：2006-04-24 21:09: とりあえず、作ってみました。以下をお試し
2018年10月31日(水) をもって、はてな認証APIの提供を終了します。それに伴い、OAuthへ移行をお願いいたします - はてなの日記 - 機能変更、お知らせなど
2018年10月31日(水) をもって、はてな認証APIの提供を終了します。それに伴い、OAuthへ移行をお願いいたします いつもはてなをご利用いただきありがとうございます。 下記の告知にて予告させていただきましたが、ご利用状況を鑑み、2018年10月31日(水)をもちまして、はてな認証APIの提供を終了させていただきます。 今後、はてなグラフ、ポケットはてななど、複数のサービスの提供を終了する予定です - はてなの日記 - 機能変更、お知らせなど はてな認証APIは、はてなアカウントによるユーザー認証をサードパーティのアプリケーションでも利用できるようにする開発者向けAPIで、2006年4月24日に公開しました。 なお、代替として、はてなではOAuthサービスプロバイダの機能を提供しておりますので、こちらのへの移行をご検討ください。 http://developer.hatena.ne.
Google Calendar に見る RSS 認証の今後の方向性 : 管理人@Yoski
先日リリースした toread.cc (あとで読むの英語版) がすごいことになっていて少々バタバタしつつも(「あとで」レポート書きます)、ひとまず落ち着いたエントリを。 さて、各所で話題になっている Google Calendar について。 （レビューは 秋元さんのブログ などで簡潔にまとめられていますので、そちらを参照して頂くとしてここでは割愛します。） さて、私が注目したのは Google Calendar の Atom フィードの配信方法です。 以前から「認証が必要なパーソナルデータをフィードで配信する方法」についてはいろいろな議論がなされていました。 少し前に一番基本的で確実といわれていたのが HTTPS + 基本認証 を用いる方法で、実際 GMail のフィードではこの方式が用いられています。 ※ GMail Atom フィード: https://gmail.google.co
子猫認証 | 秋元@サイボウズラボ・プログラマー・ブログ
via del.icio.us/popular スパム行為を行うロボットスクリプトを、正規の人間ユーザとどう見分けるか、ということで、「プログラムには(まだ)わからないけれど人間なら簡単にわかる」ような問題を使う、という方法はよく使われる。いわゆる CAPTCHA (キャプチャ)である。 CAPTCHA と言うと、まず思い浮かぶのは、ぐにゃっと曲げられたり上から線をかぶせられたりした文字列を入力させられるものだろう。機械読み取りでは認識できないように文字列を崩すことで、スクリプトの攻撃をある程度防いでいる。 しかし、特に意味のあるわけでもない読みづらいテキストを、投稿のたびに入力させられるのは、利用者にとってあまり楽しい作業とは言えないだろう。サービスがスパムで汚染されるのを防ぐために、仕方なく協力しているというところだ。 であれば、CAPTCHA の入力が、それなりに人間にとって楽しかっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
