OpenAI co-founder and Chief Scientist Ilya Sutskever is leaving the company
OpenAI co-founder and Chief Scientist Ilya Sutskever is leaving the company
認可と認証技術 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
どうも、まさとらん(@0310lan)です。 今回は、Webサービスなどを開発する際に、ユーザーの管理や識別などで必要になる「ユーザー認証」機能を、できるだけシンプルに作ってみたいと思います。 利用するのは、さまざまなバックエンド機能を提供するGoogleの【 Firebase 】です! 非常に多機能なサービスですが扱いはとてもシンプルで、簡単なコードを覚えてしまえば誰でも活用できるはずです! 自分でサーバーを用意する必要もなく、基本的な機能は無料で使えるので今すぐ始められるのも特徴と言えるでしょう。 ■始め方! 今回は、「メールアドレス」と「パスワード」でログインする一般的な「ユーザー認証」ページの作成に挑戦してみましょう! そこで、まずはFirebaseにアクセスして新規にプロジェクトを作成します。 好きな「➀プロジェクト名」と、自分の「➁国名」を指定します。 すると、プロジェクト
リンク connpass #qpstudy 2016.07 第一部 ご認証は認可ですか? (2016/07/16 14:00〜) # #qpstudy 2016.07 第一部 ## 概要 ―― ○○の三要素みたいなのってよく聞くけどさ、結局あれって何やってるの。 聞けない、いまさらそんな基礎的なこと。 インフラエンジニアになって早○年。ActiveDirectoryとかLDAPとか そういうものの話はわかるんだけど、結局基礎ってなかなか身につかないんだよね。 案件に対応するだけで精一杯だっての。 ## プログラム * 13:30 - 14:00 開場・受付 * 14:00 - 14:10 開始・ご案内 * 14:10 - 15:20
「OAuth 認証」って言葉が出てくると、「認証と認可は違う」とか言い出す人が出てきて、大体の場合「OAuth 認証」言ってた人たちがやりたいことの話とはズレた議論が始まるので、もういっその事「OAuth 認証」とは何かを定義してみましょうかね。 「OAuth 認証」で Relying Party (RP) がやりたかったこと RP (OAuth Client) は、ブラウザの前にいる人を、認証したかったんですよね? もう少し正確にいうと、ブラウザの前にいる Entity が、RP 側で把握しているどの Identity と紐付いているか、というのを知りたかったんですよね? いきなり Entity とか Identity とかいう専門用語が出てきてアレですが、そのあたりのことは先日の OpenID TechNight #13 でもお話ししたので、以下のスライドの Entity・Identi
よく訓練されたアップル信者、都元です。「認証 認可」でググると保育園の話が山程出て来ます。が、今日は保育園の話ではありません。そちらを期待した方はごめんなさい。こちらからお帰りください。 さて、先日のDevelopers.IO 2016において、マイクロWebアプリケーションというテーマでお話させて頂きました。一言で言うと OAuth 2.0 と OpenID Connect 1.0 のお話だったのですが、これらを理解するにあたっては「認証」と「認可」をはっきりと別のものとしてクッキリと認識する必要があります。 まず、ざっくりとした理解 認証と認可は密接に絡み合っている一方で全く別の概念です。正直、理解は簡単ではないと思います。 まず「認証」は英語では Authentication と言います。長いので略して AuthN と書いたりすることもあります。意味としては 通信の相手が誰(何)であ
インフラストラクチャー部 id:sora_h です。クックパッドでは、社内向けの Web アプリ (以降 “社内ツール”) を社外のネットワークから利用する際、アプリケーションレベルでのアクセス制御とは別に、リバースプロキシでもアクセス制御を実施しています。*1 これまで BASIC 認証あるいは VPN による社内ネットワークを経由した接続という形で許可していました。しかし、iOS の Safari などでは BASIC 認証時のパスワードを保存できない上、頻繁に入力を求められてしまいますし、VPN はリンクを開く前に接続をしておく必要があります。これにより、社内ツールを社外で開く時に手間がかかってしまう問題がありました。 これに対し、一部では typester/gate などを導入し Google Apps での認証を行なっていました。しかしいくつか問題があり、非アドホックな対応では
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog saegusa2017-04-16Yoshihiro was a network engineer at LINE, responsible for all levels of LINE's infrastructure. Since being named Infra Platform Department manager, he is finding ways to apply LINE's technology and business goals to the platform. こんにちは。LINEでネットワークやデータセンターを担当している三枝です。2017年1月にJANOG39で登壇する機会を頂きましたので、今回
【これは約 16 分の記事です】 (2015年の投稿のため、リンク切れや情報が古くなっている部分が一部ございます) 定期的なパスワード変更を奨めるサービス提供者や行政 ID・パスワードが流出する事件を受け、提供者や行政提供者側からユーザに対してセキュリティ対策の実施を喚起しています。 IDとパスワードの適切な管理 :警視庁(リング切れ) この中で、「パスワードの定期的変更」がうたわれています。このパスワードの定期変更については、セキュリティ対策として余り有効ではないという方は結構いらっしゃいます。 パスワードの定期的変更に関する徳丸の意見まとめ http://tumblr.tokumaru.org/post/38756508780/about-changing-passwords-regularly 実際、パスワードはどれくらいの頻度で変えるべきですか? | ライフハッカー[日本版] ht
米Twitterは10月22日(現地時間)、モバイル開発者に向けた初めてのカンファレンス「Twitter Flight」をサンフランシスコで開き、モバイルアプリ開発プラットフォーム「Fabric」を発表した。障害報告や広告管理などこれまで提供してきた開発者向けツールに加え、電話番号とSMSで認証・ログインできる新機能「Digits」も搭載する。利用は無料だ。 モバイルアプリ開発時に重要な(1)安定性を高める、(2)利用者を増やす、(3)収益化、(4)ユーザー認証――の4つの側面を網羅したという開発キット。これまで提供してきたAPIやOAuth、「Twitter Cards」などの埋め込み機能、障害報告ツール「Crashlytics」や広告管理ツール「MoPub」などを一元管理し、アプリ開発時に使える機能を数行のコードを追加することで簡単に組み込むことができる。 アカウント認証ツールとして、
Kibana や Grafana を使う時に、これらはjsのツールなので、 Erasticsearch や InfluxDB といったバックエンドサービスにjsからアクセスできるようにする必要がある。 そのためには、 普通にバックエンドサービスのportを開放 nginxとかでリバースプロクシ とかする必要があり、めんどくさい。 さらにセキュリティのことを考えると、2の方法のうえに、nginxでSSL+Basic認証なんかにする必要があってよりめんどくさい。 さらに、僕はBasic認証が嫌いだ。 昔は Firefox + 1Password で良い感じにBasic認証の入力が行えたが、いまはだめになってしまったし、 Basic認証だとアカウントの管理もめんどくさい。 なので、Google認証なhttpdでリバースプロクシもできる、gateというツールを作った。 https://github
■背景 自社のサーバと通信する自社アプリについて、本来不要であるにも関わらず他社であるCAに認証情報の管理を委託することが多いわけですが、CAが証明書を誤発行した結果情報漏洩が発生したとして、その責任は自社にはないと主張できるのか、もう一度考えなおしたほうがいいんじゃないかと思うんです — Kazuho Oku (@kazuho) July 15, 2014 .@ockeghem @smbd @ando_Tw スマホアプリの提供においてはコードの署名鍵を安全に管理することが求められますが、その前提において通信相手の認証管理をCAに委託することにどれほどの意味があるんでしょう — Kazuho Oku (@kazuho) July 14, 2014 ■他社CAは信頼できるのか 特定のCAにpinningするのはしないより安全だけど、そもそも誤発行しないCAなんてあるのかという議論は重要。見知
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く