Web APIにおける認可の現状確認 2019 春 - 解せぬ日記
最近Web APIの認可について思いを馳せる機会があったのだけど、どの方法で認可を実装するのがスタンダードなのか、そもそもそんなものは最初からないのか、よく分からなくなったので自分なりの考えをまとめることにした。 ファーストパーティのアプリが使うWeb API（プライベートなWeb API）の場合はセッションを使うケースもあるだろうが、セッションを使うケースでは悩むことも少なかったので、ここではアクセストークンを用いた認可にフォーカスして考えてみたい。ケースとしてはユーザー毎にアクセストークンが発行され、Browser-BasedアプリやNativeアプリからWeb APIが叩かれることを想定している。 追記 2019/03/04 認証や認可周りについてよく拝見させてもらっている方にブログで言及していただきました。合わせて読むことをお勧めします。 ritou.hatenablog.com
認可と認証技術についてのスライドを書きました - 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
OAuth 2.0 全フローの図解と動画 - Qiita
RFC 6749 (The OAuth 2.0 Authorization Framework) で定義されている 4 つの認可フロー、および、リフレッシュトークンを用いてアクセストークンの再発行を受けるフローの図解及び動画です。動画は YouTube へのリンクとなっています。 English version: Diagrams And Movies Of All The OAuth 2.0 Flows 追記 (2019-07-02) 認可決定エンドポイントからクライアントに認可コードやアクセストークンを渡す方法については、別記事『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』で解説していますので、ご参照ください。 追記（2020-03-20） この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！ 1. 認可コードフロー RF
Big Sky :: コマンドラインアプリで OAuth2 認証を使う際に使えるテクニック
OAuth2 でレスポンスタイプがコードもしくはトークンの場合、ブラウザで認証を行ってコードやトークンを自前サーバで受け取る事になる。モバイルアプリだと組み込みブラウザが前提になっておりリダイレクトの最終 URL からアクセスコードやトークンを得る。ただコマンドラインアプリの場合、認証の為に起動したブラウザの最終 URL を得る方法はない。また1コマンドラインアプリケーションの為にドメイン付きのコールバックサーバを用意するのも面倒だし、作ったサーバをユーザに信用して貰う必要がある。あとそもそも外部のサーバで受け取ったトークンをどうやってコマンドラインアプリに渡すかという問題がある。 そこで使うのがローカルサーバを立てる方法。認証後のコールバック先をコマンドラインアプリから起動したローカルサーバにし、そこにリダイレクトさせてアクセストークンを貰い保存する。 今日はこれが伝わり易い用に Mic
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
認証は単純な概念で、別の言葉で言えば本人確認です。Web サイトにおける本人確認の最も一般的な方法は ID とパスワードの組を提示してもらうことですが、指紋や虹彩などの生体情報を用いた本人確認方法もありえます。どのような確認方法だとしても (ワンタイムパスワードを使ったり、2-way 認証だったりしても)、認証とは、誰なのかを特定するための処理です。開発者の言葉でこれを表現すると、「認証とは、ユーザーの一意識別子を特定する処理」と言えます。 一方、認可のほうは、「誰が」、「誰に」、「何の権限を」、という三つの要素が出てくるため、複雑になります。加えて、話をややこしくしているのは、この三つの要素のうち、「誰が」を決める処理が「認証処理」であるという点です。すなわち、認可処理にはその一部として認証処理が含まれているため、話がややこしくなっているのです。 認可の三要素をもう少し現場に近い言葉で表
gateを使って手軽に認証を導入する - pixiv inside [archive]
ISUCON4 で準優勝した @catatsuy です。 賞金の使い道はまだ考えていません。 ところでピクシブ株式会社では冬インターンをやります！ エンジニア向け pixiv開発のbugリストからの脱出！エンジニア職インターン - ピクシブ株式会社 採用サイト ISUCON4 の予選問題を解くだけでインターンに参加できるチャンスなのでぜひ挑戦してみてください！！1 pixiv/intern2014w この記事は当初はアドベントカレンダーの記事にする予定でしたが，今が旬だと圧力をかけられたので今公開します。 なおこの記事は ピクシブ株式会社 Advent Calendar 2014 - Qiita の -17 日目の記事です。 今までの社内ツールの認証は各サーバーに設定されていたために退職者などの対応が非常に大変でした。そこで最近のピクシブ株式会社では typester/gate を導入する
![gateを使って手軽に認証を導入する - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/f234db5d7f70f2a8afe476e78ede9c5167fc67c1/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fc%2Fcatatsuy%2F20141114%2F20141114192037.png)
iOSでOAuth2認証を行う(feedlyクライアントの作成)
The feedly Cloud APIが一般公開されていることはご存知の方は多いと思うが、APIを利用している方は そう多く無いのではないだろうか。 The feedly Cloud APIはsandboxという形式で開発者に開発用環境を提供している。 開発の序盤はこの開発環境を使用してAPIの使用方法やアプリの動作確認を行い、 その後リリースする準備が出来たら本環境で利用可能なクライアントIDを払い出してもらう という流れになると思う。(本環境に対応したクライアントIDの払い出しは別途Emailで申請する必要があるようだ) The feedly Cloud APIを使用するにはまずOAuth2認証が必要だ。これが一番厄介で(昔よりは良くなっている) 認証さえ済ませてしまえば、後はAPIを呼び出して必要な情報を取り出し、好きなように処理すれば良い。 iOS用のOAuth2ライブラリが存在
OAuth 2.0のbearer tokenの最新仕様を調べたらあまり変わってなかった - r-weblife
追記：最新仕様はRFC化されています。 The OAuth 2.0 Authorization Framework: Bearer Token Usage（日本語） こんばんは、ritouです。 OAuth 2.0にはWGで議論され日々更新されているDraft仕様がたくさんあるわけですが、今回はOAuth 2.0のリソースアクセスの象徴ともいえる"bearer token"の最新仕様を確認します。 "OAuth 2.0ではリソースアクセス時に署名がいらなくなった"というような話を聞いたことがある人も多いと思いますが、それが"bearer token"と呼ばれるToken Typeになります。 最初はOAuth 2.0の本体の仕様に含まれていたのですが、途中で関連仕様として独立しています。 最新の仕様はこちらです。 draft-ietf-oauth-v2-bearer-04 - The OA
Rails4に対応したgem doorkeeperついて調べてみた。 - Qiita
Ruby on Rails Advent Calendar 2日目遅れました(^o^) -- タイトルの通りですが、以前ブログに書いた事がある自社サービスの機能を簡単にAPIで提供出来てしまう！gem doorkeeperが凄い。 という記事を書いて1年以上経ちました。 doorkeeperも大分進化しており、Rails4対応もしている様なので再度検証してみることにしました。 下記作業ログになります。 検証環境 ruby 2.0.0p353 Rails 4.0.1 Gemfileにdoorkeer追加 Gemfileにdoorkeeperを追加します。 GET /oauth/authorize/:code(.:format) doorkeeper/authorizations#show oauth_authorization GET /oauth/authorize(.:format) d
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
The OAuth 2.0 Authorization Framework: Bearer Token Usage（日本語）
The OAuth 2.0 Authorization Framework: Bearer Token Usage（日本語） Abstract この仕様書は, OAuth 2.0の保護リソースへアクセスするために, 署名無しトークンをHTTPリクエスト中でどのように利用するか記述したものである. 署名無しトークンを所有する任意のパーティ (持参人) は, 関連づけられたリソースへアクセスするために署名無しトークンを利用できる (暗号鍵の所有を示す必要はない). 誤った利用を避けるために, 署名無しトークンは保存場所や流通経路での値の露見から守られる必要がある. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Enginee
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OAuth2.0 Proof of Possession についてまとめてみた - hiyosi's blog
GitHub - sorah/nginx_omniauth_adapter: Use omniauth for nginx auth_request
GitHub - googleapis/signet: Signet is an OAuth 1.0 / OAuth 2.0 implementation.
GitHub - songkick/oauth2-provider: Simple OAuth 2.0 provider toolkit
GitHub - takuran/OAuth2ClientExample: OAuth2 client example using the OAuth2Client project for iOS.
GitHub - gabrielrinaldi/GROAuth2SessionManager: OAuth2 authentication helper based on AFNetworking's AFHTTPSessionManager
GitHub - doorkeeper-gem/doorkeeper: Doorkeeper is an OAuth 2 provider for Ruby on Rails / Grape.
Help And Training Community
SDKを利用しない場合 - Yahoo!デベロッパーネットワーク
