フィードバックを送信 OAuth 2.0 を使用して Google API にアクセスする コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Google API では、認証と承認に OAuth 2.0 プロトコルを使用しています。Google は、ウェブサーバー、クライアントサイド、インストール済み、入力制限のあるデバイスのアプリケーションなど、OAuth 2.0 の一般的なシナリオに対応しています。 まず、 Google API Console から OAuth 2.0 クライアント認証情報を取得します。次に、クライアント アプリケーションが Google 認可サーバーにアクセス トークンをリクエストし、レスポンスからトークンを抽出して、アクセスする Google API にトークンを送信します。Google で OAuth 2.0 を使用することについ
認証は単純な概念で、別の言葉で言えば本人確認です。Web サイトにおける本人確認の最も一般的な方法は ID とパスワードの組を提示してもらうことですが、指紋や虹彩などの生体情報を用いた本人確認方法もありえます。どのような確認方法だとしても (ワンタイムパスワードを使ったり、2-way 認証だったりしても)、認証とは、誰なのかを特定するための処理です。開発者の言葉でこれを表現すると、「認証とは、ユーザーの一意識別子を特定する処理」と言えます。 一方、認可のほうは、「誰が」、「誰に」、「何の権限を」、という三つの要素が出てくるため、複雑になります。加えて、話をややこしくしているのは、この三つの要素のうち、「誰が」を決める処理が「認証処理」であるという点です。すなわち、認可処理にはその一部として認証処理が含まれているため、話がややこしくなっているのです。 認可の三要素をもう少し現場に近い言葉で表
次世代のOpenIDとして仕様策定・実装が進んでいるOpenID Connectについて紹介します。 昨年RFC化されたOAuth 2.0はいまやAPIアクセスによるユーザーデータの活用に必要不可欠な存在です。 また、取得したユーザー識別子により認証連携の手段としても利用されていますが、サービス毎に微妙に異なる仕様は開発者を悩ませていることでしょう。 OpenID ConnectではOAuth 2.0の使い易さをそのままに、認証連携を安全に行うために必要な機能が定義された標準化仕様であり、Googleなどいくつかのサービスでは既に利用できる状態にあります。本セッションでは、次のような内容を通してOpenID Connectの魅力をお伝えできればと思っています。 OAuth 2.0との違いについて 最新の仕様策定状況、採用しているサービスについて PerlのServer/Client用 ライ
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita ってのになんかフォローアップしろよ的なのが来たので。 ざっと読んだ感想としては、「OpenID Connect の OPTIONAL な機能全部実装したら、そら大変ですね」という感じ。（Authlete に関しては、OpenAM みたいな感じで使われる、OpenAM よりはるかに簡単に使える代わりに有料の何かなんだろうな、というイメージです） OAuth は必要なのか？ Basic 認証は死んだ。 ユーザー単位での API のアクセスコントロールがしたいです。 っていう前提で話すると、OAuth 以外まともな選択肢が無いんじゃないでしょうか。 OAuth の各種 Extension (RFC 6749 & 6750 以外にいろいろある) に関しては、適宜必要なのを実装すればいいんだけど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
