アプリで「ログインしっぱなし」はどのように実現されているか？ - Qiita
このツイートを見て、「アプリで再ログインを頻繁要求されるってユーザビリティ良くないな。」と思ったのですが、普段裏側の仕組みは意識していなかったりテックリードの方に任せきりだったりしていたので、これを機に調べてみました。 そもそもスマホアプリ の時代、もはやauthenticationですらないと思うのよね。（何を言ってるかわからねえだろうと思うが。） — Hiromitsu Takagi (@HiromitsuTakagi) 2019年7月8日 この記事は「アプリでログインしっぱなしは、どのように実現されるの？」という疑問と調べた結果を共有するために書いていきます。 間違いや「もっとこんな仕組みが使われてるよ！」等のツッコミがあれば、どしどし貰えると助かります！ 疑問1. アクセストークンという仕組みとは？ 「なぜアクセストークンという概念が必要なのか？」 モバイルアプリでユーザー認証をし
Get started using OneDrive API - OneDrive dev center | Microsoft Docs
このページでは、Microsoft Graph と OneDrive API を使用するために必要になる手順の概要について簡単に説明します。 詳細な手順については、「Microsoft Graph クイック スタート」を確認してください。 SharePoint Server 2016 を使用して作業する場合、または Microsoft Graph を使用しない場合は、「SharePoint Server 2016 で OneDrive API を使用する」のトピックを参照してください。 1. ユーザー認証とアプリの承認 Microsoft Graph および OneDrive API では、承認に OAuth 2.0 を使用します。 OAuth フローを完了すると、アプリはユーザーの代わりに特定のアクセス許可のセットである Microsoft Grap へのアクセスを提供するアクセス トー
WP REST API の OAuth 認証の方法と何が起こっているのかとなぜそんなことをしているのか - Shinichi Nishikawa's
STEP 0: Client Key と Client Secret を作成する ドキュメントサイトの方には「OAuth のプラグインにUIはありません。そのうち作ります」などと書かれておりましたが、実際にはありました。 Name と Description は管理用のものだと思われますので適当に入れます。Callback URL はよく分からないですが必須なので /success としました。 Client Key と Client Secret をメモしておきましょう。 OAuth フローの概要と、その意義 OAuth1/Auth-Flow.md at master · WP-API/OAuth1 にある OAuth 認証のフローを翻訳します。クライアント側から見ると、3つのフローに分かれています。 Temporary Credentials Acquisition: The clie
PHPでOAuth認証して自分のつぶやきを表示する [Twitter API 1.1 対応版]
「Name」は独自のものにする必要があります。 「Website」は設置するサイトに変更してください。 「Callback URL」はユーザーに認証させる場合は必要ですが、今回は自分のツイートを表示するだけなので必要ないです。 「Yes, I agree」にチェックして「Create your Twitter application」ボタンをクリックします。 「Consumer key」と「Consumer secret」をメモして、「Create my access token」をクリックします。 画面が遷移して Your access token という欄が増えますので「Access token」「Access token secret」をメモしておきます。 PHPで自分のつぶやきを表示 認証にはライブラリを使用すると簡単です、今回は「abraham/twitteroauth」というの
![PHPでOAuth認証して自分のつぶやきを表示する [Twitter API 1.1 対応版]](https://cdn-ak-scissors.b.st-hatena.com/image/square/3c656f720529566f7ffcdc66f1339f9bf828e178/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fwww.webopixel.net%2Fblog%2Fwp-content%2Fuploads%2F2012%2F12%2F1220s.png){kind=tracking}
mixiへの認証を行ってくれる「OmniAuth-mixi」を公開しました - mixi engineer blog
こんにちは。よういちろうです。Ruby on RailsやSinatraで作るWebアプリケーションに各種認証機能を手軽に追加できる機構として、「OmniAuthシリーズ」があります。これのmixi版を作ってみました。 OmniAuth-mixi - Github OmniAuthは、Strategyという形式で任意の認証プロバイダの実装を追加できるようになっています。OmniAuth-mixiを使うことで、OAuth2にてmixi Graph APIの認証認可を行い、People APIで認可ユーザのプロフィール情報を取得する、という処理を行ってくれます。 使い方は簡単です。Ruby on Railsの場合、まずGemfileに以下を追記します。 gem 'omniauth-mixi' 次に、config/initializers/omniauth.rbファイルを以下の内容で作成します。
mixi PlatformがOAuth 2.0の最新仕様に対応しました - mixi engineer blog
はじめまして、研究開発グループのritouです。 人々が7インチタブレットの話題で盛り上がっていた10月24日、mixi PlatformはOAuth 2.0の最新仕様のサポートを開始しました。 OAuth2.0 RFC6749へ対応しました << mixi Developer Center (ミクシィ デベロッパーセンター) その内容について紹介します。 mixi Graph APIとOAuth 2.0の進化 Webアプリ、モバイルアプリなどがmixi Graph APIを用いてユーザーデータにアクセスする際、ユーザーから許可を得る必要があります。mixiアプリやmixiページアプリからもmixi Graph APIを利用できます。認証認可と呼ばれるこの機能の実装について、今まではOAuth 2.0 draft v.10をサポートしてきました。 OAuth 2.0の仕様策定の中で、201
RFCとなった「OAuth 2.0」――その要点は？
RFCとなった「OAuth 2.0」――その要点は？：デジタル・アイデンティティ技術最新動向（2）（1/2 ページ） いまWebの世界では、さまざまなWebサービスが提供するプラットフォームと、サー ドパーティが提供するアプリケーションがAPIを中心に結び付き、一種の「APIエコノミー」を形成しています。この連載では、そこで重要な役割を果たす「デジタル・アイデンティティ」について理解を深めていきます。 再び、デジタル・アイデンティティの世界へようこそ 前回「『OAuth』の基本動作を知る」ではOAuthの仕様がどういうものかについて説明しました。今回は引き続き、 OAuth 1.0とOAuth 2.0の違い OAuth 2.0をセキュアに使うために知っておくべきこと について述べていきます。 OAuth 1.0とOAuth 2.0の違い クライアントタイプの定義 OAuth 2.0では、O
「OAuth」の基本動作を知る
デジタル・アイデンティティの世界へようこそ はじめまして、OpenID Foundation JapanでエバンジェリストをしているNovです。 この連載では、僕を含めOpenID Foundation Japanにかかわるメンバーで、OpenID ConnectやOAuthなどの「デジタル・アイデンティティ（Digital Identity）」にかかわる技術について紹介していきます。 APIエコノミー時代のデジタル・アイデンティティ 世界中で9億人のユーザーを抱える「Facebook」や5億人のユーザーを持つ「Twitter」など、巨大なソーシャルグラフを持つサービスが、日々その存在感を増しています。日本でも、グリーやモバゲーなどがそれぞれソーシャルゲームプラットフォームを公開し、国内に一気に巨大なソーシャルゲーム市場を作り上げました。最近では、ユーザー数が5000万人を突破し、プラット
Twitterの規約変更でクライアントアプリがオワタ | 拷問iPhoneアプリ開発
[追記] 以前は”クライアントアプリとキュレーションがオワタ”というタイトルだったけど、混乱するコミュニティーに対し、Twitter側から新情報が出たので変えました。(最後の追記を参照) [追記]新しく分かった事柄などを整理した記事を書きました。 TweetBotのメッセージと新しいTwitterAPIルールの整理 TwitterAPIの新しい規約詳細が出た！ https://dev.twitter.com/blog/changes-coming-to-twitter-api ６月の終わりに、Twitterがブログで、「Twitterアプリのパクリだったり、エコシステムにそぐわないアプリは禁止するよう規約変更があります。。。」と意味深げな事を語って、開発者のコミュニティーがずっと大騒ぎでした。 Twitterのブログ記事の衝撃はたいへんなもので、内容がはっきりとしてなく、一見開発コミュニテ
米連邦裁判所、「コードは財産ではない」との見解を示す | スラッシュドット・ジャパン YRO
取り敢えずこれは、他の人も書いている攻殻機動隊みたいなものを今すぐ実現しようとするものじゃない、 例えば、人工無能とか(ELIZAとか)Siriといったものに、実在の/実在した人の人格を「風味」として加えるというもの。 お掃除ロボットの応答メッセージを仮想のツンデレ娘風にするのではなく、高倉健風とかにできる、 障害物で進めなくなったら「ちょっとー何とかしてよコレ」ではなく「自分不器用ですから」と喋るようなる。 どこかの政治家の人格を入れたら「善処するよう指示いたします」となる。 （攻殻機動隊と違ってお掃除ロボットが立ち往生しても人格を提供した側にフィードバックの必要はない） 特徴データベースの抽出や作成をどこまで機械的にできるかは解からないけれど、まだ生きている人なら 本人にそれぞれの状況に応じた対応をして貰ってそれを逐次記録するという手もある。 今の技術でも上記のようなものは実現可能。
mixi Graph APIのOAuth 2.0を使った認証認可手順をフローチャートにしてみた
Developer Centerのドキュメントはすごく良くまとまっていて、mixi Graph APIの認証認可手順の部分も分かりやすくまとまっています。が、フローチャートがあったらもっと分かりやすいのになぁと思ったので自分で作ってみました。 上記イメージはCC BY-NC 3.0ライセンスで。 アクセストークンとリフレッシュトークンを取得するまでのフローです。「認証認可手順」のドキュメントを紐解く際に、このチャートが役に立てば幸いです。 ※2011年2月12日現在の仕様をもとに作ったフローチャートです。 ※詳細はドキュメントで！ 2011年2月13日に公開され、2011年7月4日に更新された記事です。 About the author 「明日のウェブ制作に役立つアイディア」をテーマにこのブログを書いています。アメリカの大学を卒業後、ボストン近郊のウェブ制作会社に勤務。帰国後、東京のウェブ
いまさらですけど「OAuthなら安心」という誤解について
Twitter の BASIC 認証が廃止され OAuth が標準の認証方法になりましたね。 BASIC 認証と OAuth ものすごく簡単に言うと、 BASIC 認証というのは毎回 ID とパスワードを使う認証方法なので 外部のサービスを利用するには その運営者に ID とパスワードを預けることになる。 それに対して OAuth というのは Twitter から専用のアクセストークンというものが提供され アプリケーションはそのトークンを使って Twitter にアクセスするので 外部サービス運営者にパスワードを渡す必要がない。 そのサービスの利用をやめたい場合も サービス側に申請する必要はなく、 Twitter のサイト上で「許可を取り消す」というボタンを押すだけ。 これは安心。 安心じゃない 確かに、ID とパスワードを渡すということは 相手がその気になれば何でもできるということ。 ア
Twitter、BASIC認証を6月末に終了 OAuthとxAuthのみに
米Twitterは、TwitterのAPIのBASIC認証を6月末に終了する。OAuthかxAuthのみにし、セキュリティを強化する狙い。BASIC認証を採用しているサービスに、OAuthかxAuthへの移行を呼び掛けている。 BASIC認証は、ユーザー名・パスワードを入力する認証方式だが、APIを使ってサービスを構築しているサードパーティにID・パスワードが渡るという問題がある。 Twitterでは、ID・パスワードを渡さずにトークンでAPI認証できるOAuthと、OAuthの簡易版で、デスクトップアプリなどでも利用できる「xAuth」も提供しており、BASIC認証のサービス提供者に移行を呼び掛けている。
APIアクセス権を委譲するプロトコル、OAuthを知る ― ＠IT
クロスドメインでのデジタルアイデンティティを守る APIアクセス権を委譲するプロトコル、 OAuthを知る 作島 立樹 NRIパシフィック 2008/1/21 マッシュアップと呼ばれる仕組みで、既存のWebサービスが次々とつながり、新たなサービスが登場している。しかし、メールアドレスなど重要な個人情報が意図せずに「つながれてしまう」可能性もある。そこで登場したのがアクセス権の「委譲」を目的としたプロトコル、OAuthである。本記事ではOAuthの仕組みとともに、なぜそれが登場したのかという背景にも触れる（編集部） マッシュアップの犠牲になるユーザーのアイデンティティ GETなどのHTTPメソッドをもちいてURLへリクエストする、いわゆる「RESTful」【注1】なWeb APIを使ったアプリケーション同士の交流は、いままさに隆盛を極めている。「マッシュアップ」と呼ばれているこのサービス形態
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
YAPC::Tokyo 2013 ritou OpenID Connect
ブログ