図解 OpenID Connect による ID 連携 - Qiita
ID 連携フローの説明 1 ウェブブラウザを使い、ウェブサービスのログインページにアクセスします。 2 ウェブサービスはログインページを生成し、ウェブブラウザに返します。ウェブサービスが外部のアイデンティティプロバイダ（IdP）との ID 連携をサポートしていれば、ログインページ内に ID 連携を開始するためのリンクが埋め込まれます。 3 ID 連携を開始するためのリンクをクリックします。 4 ID 連携開始の要望を受けたウェブサービスは、対象となる IdP への認証リクエスト（OpenID Connect Core 1.0 Section 3.1.2.1. Authentication Request）を作成します。 認証リクエストの形式は、リクエストパラメーター群を含めた、IdP の認可エンドポイント（RFC 6749 Section 3.1. Authorization Endpoi
IPA ISEC セキュア・プログラミング講座：Webアプリケーション編 第2章 アクセス制御
複数のWebアプリケーションがユーザ認証の機能を外部に一元化することによって、ユーザがパスワードを覚える負担を低減することができる。また、Webアプリケーションのオーナは、パーソナル情報の管理の負担とリスクを外部に転嫁することができる。 外部のユーザ認証サービスと連係動作するしくみ パスワードを用いたユーザ認証機能として、Webアプリケーションから利用可能な外部サービスが、2005年頃から提供されるようになってきた。 参考資料： 『アイデンティティ管理技術解説』 ユーザによるアクセス要求を遮断できるコードを開発して、そこから外部のユーザ認証サービスとアクセス認可判定の処理を順に呼び出すようにする。この要求を遮断できるコードは、PEP（Policy Enforcement Point）の役割を果たす。 ユーザ認証の結果をPEPに伝達するしくみとしては、「HTTPリダイレクト」の機能が応用され
RailsにDevise+OmniAuthでユーザ認証を実装する手順 - Qiita
Ruby on Railsアプリケーションに、以下の認証方法を実装する。 今回は1→2の順序で実装する。 メールアドレス OAuth（Facebook/Twitter） 動作環境 Ruby on Rails 4.1.1 Devise 3.3.0 OmniAuth 1.2.2 全体の概要 先に以下の記事に目を通すことで、全体の概要を把握することができる。 http://post.simplie.jp/posts/43 http://qiita.com/mosa_siru/items/9f1faa509f4d3653a1b2 http://qiita.com/ytkt/items/d78841f7dea5e29f38ee http://easyramble.com/implement-devise-and-ominiauth-on-rails.html https://github.com/p
ウェブアプリ開発日誌：Rails5でユーザ登録機能を実装するまでのあれこれ - オフトゥン大好き。
Railsアプリにユーザ登録・認証を実装するまでの手順を書きます。ここでいうユーザ登録は、よくあるユーザ名とメールアドレスを入力して届いた認証リンクにアクセスするとアクティベートされるタイプのやつです。 環境 rails new deviseを導入する Userモデルの作成 figaroを導入 twitter認証を追加する APIトークンとシークレットを設定する OAuth用のマイグレーションを作成する callback用のコントローラを作る 参考文献 環境 Ruby 2.3.0 Rails5 (5.0.2) devise (4.2.0) omniauth, omniauth-twitter figaro rails new プロジェクトディレクトリを作ります。今回はデータベースにMySQLを使うのと、テストにはRSpecを使いたいのでデフォルトのテストは外しておきました。 rails n
Devise+OmniAuthでQiita風の複数プロバイダ認証 - Qiita
経緯 QiitaのようなOAuth認証を実装しようと試みた。 ググってみると、ユーザーをログインさせた後どうするかについて言及されていないものが多かった。 いろんな記事からアイデアを吸収して試行錯誤した結果、自分の思い通りの仕様に仕上がったので今後のためにメモ。 スタートの時点でこれらの記事が非常に参考になった。 RailsでいろんなSNSとOAuth連携/ログインする方法 Rails4 で Devise と OmniAuth で、Twitter/Facebook のOAuth認証と通常フォームでの認証を併用して実装 やりたいこと Devise認証付Railsアプリに、OmniAuthを追加し各ユーザーを複数のプロバイダで認証できる様にしたい。（ユーザーと全てのプロバイダーを紐付けする） Qiitaの仕様を目標とする。 プロバイダーを増やせるように拡張性を持たせる。 新規登録（３パターン）
JavaでTwitterのOAuthを書いてみました - n3104のブログ
OAuthについて前々から気になっていたので、やる夫と Python で学ぶ Twitter の OAuth - YoshioriのBlogを真似する感じでJavaで書いてみました。なお、あまり意味はないのですがJDKのライブラリのみで作成しました。 ※ 2013-08-03 に動作確認済みです。なお、その際に statuses/update API の Resource URL を 1.1 に更新しました。 OAuthの概要 要はユーザーIDとパスワードではなくトークンを利用して認証を行う仕組みです。OAuthプロトコルの中身をざっくり解説してみるよ - ゆろよろ日記がとても分かりやすいです。 実際に実装する際はAuthenticating Requests with OAuth | dev.twitter.comがマニュアルになります。あとは、用語や定義について確認したいことがあればR
OAuthコンシューマの仕組みと実装 〜 Ruby編 - しばそんノート
前置き 前回の記事でOAuthを使ってTwitter APIにアクセスすることができるようになりましたが、ruby-oauthは内部でNet::HTTPを呼び出しているため、そのままではGoogle App Engine for Java上のJRuby(以下JRuby for GAE/J)で利用できません。 「JRuby for GAE/JでもNet::HTTPが使えるようになる」というrb-gae-supportと組み合わせればOKなのかもしれませんが*1、OAuthの仕様自体はシンプルなものですし、せっかくなので勉強がてら自分で実装してみることにします。 車輪の再発明おいしいです！*2 ちなみにタイトルにRuby編と付いていますが、他の言語編を作成する予定は特にありません。 OAuthの仕様 実装の前にOAuthの仕様や、そもそもの成り立ちについて調べました。既にわかりやすいまとめ記事
OAuth Signatureの検証方法について << mixi Developer Center (ミクシィ デベロッパーセンター)
OAuth Signatureの生成方法 http://example.com/foo/?opensocial_app_id=123&opensocial_owner_id=xxxxxxxx にGETリクエストが送信された場合を例として、OAuth Signatureの生成方法を以下に説明します。 まず、署名生成に必要なベース文字列を生成するために次の値を用意します。 HTTPリクエストメソッド リクエストURL。クエリーパラメータは含めないようにします。 OAuthの処理に必要な各種パラメータを設定します。クエリーパラメータはこちらに含めます。パラメータの順序は、予めパラメータ名のアルファベット順にソートしておく必要があります。 例えば、下記のような値を用意します。 GET http://example.com/foo/ oauth_consumer_key=bc906fac81f581
OAuthプロトコルの中身をざっくり解説してみるよ - ( ꒪⌓꒪) ゆるよろ日記
「おーおーっすっ!」 てなこって、TwitterのAPIのBASIC認証も6月末に終了してOAuth/xAuthに移行するというこの時期に、あらためてOAuthについて勉強してみたんですのよ? OAuth認証を利用するライブラリは各言語で出そろってきてるのでそれを使えばいんじゃまいか? というと話が終わるので、じゃあそのライブラリの中身はなにやってんのよってことを、OAuthするScalaのライブラリ作りながら調べたことをまとめてみました。 間違っているところもあると思うのでツッコミ歓迎です＞＜ OAuthってそもそもなんなの? ものすごくざっくりというと「API利用側が、ユーザ認証をAPI提供サービス側にやってもらうための仕様」って感じでしょうか? BASIC認証の場合、API利用側が認証に必要なアカウントやパスワードを預かる必要があるわけです。悪意のあるAPI利用側が「なんとかメーカー
OAuth 2.0 の仕組みと認証方法
OAuth 2.0 の仕組みと認証方法について説明します。OAuth 1.0 の認証フローとそれらの問題点から、OAuth 2.0 の認証フロー、認可コード、アクセストークン、リフレッシュトークンまで網羅します。
アクセストークンに有効期限を設けるべきかどうか - Qiita
OAuthプロバイダを提供することになったとして、アクセストークンに有効期限を設けるべきかどうかについて考えたい。OAuth 2.0の仕様にはアクセストークンの期限切れに関係する仕様が定義されているし、セキュリティをより強固にするためにアクセストークンは一定期間で期限切れにするべきだという主張があったと思う (確認していないので無いかもしれない)。しかしながら、例えばGitHub API v3ではアクセストークンに有効期限を設けていない。この投稿では、アクセストークンの有効期限に関係して起こり得る問題を取り上げる。 アクセストークンに有効期限を持たせておくとちょっと安全 アクセストークンが悪意のある第三者に漏洩してしまった場合、そのアクセストークンに認可されているあらゆる操作が実行可能になってしまうという問題がまず存在する。ここでもしアクセストークンに有効期限が存在していたとすれば、その操
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - royclarkson/spring-rest-service-oauth: A simple OAuth protected REST service built with Spring Boot and Spring Security OAuth