サバフェス 2016 Yahoo! ID連携のご紹介 〜OpenID Connect入門〜タイトル： 『サバフェス 2016 Yahoo! ID連携のご紹介 〜OpenID Connect入門〜』 概要： OpenID Connectの解説とYahoo! ID連携のご紹介とIoTデバイスとの連携方法をご紹介します。 サバフェス 2016 -Health Engineering with IoT- March. 17 2016 URL：http://2016.serverfesta.info/
OAuth for Native Apps | GREE Engineering
GREE Advent Calendar 9日目は @nov が担当します。 僕は GREE ではセキュリティ部に所属しており、社外では OAuth や OpenID Connect などの Identity 関連技術についての翻訳や講演などを行ったりもしています。 今日は GREE Advent Calendar ということで、Native App コンテキストでの OAuth の話を少し書いてみようと思います。 はじめに Native App を開発していると、Backend Server とのやりとりや Facebook Login や Google Sign-in などで、必ずと言っていいほど OAuth 2.0 というのが出てきます。 OAuth 1.0 と異なりリクエストに署名が不要だったり、Client Secret (a.k.a Consumer Secret) 無しでも
RFC7636として発行されたOAuth PKCEとは - r-weblife
おひさしぶりです、ritouです。 今日は家で風邪治してましたが、TLに流れてきた次世代なんちゃらの話題に乗っかって、ざっくりとした仕様紹介です。 ベンダー個別のパスワード管理には課税せよ！？ 次世代Webカンファレンス『identity』 #nextwebconf #nextwebconf407 - Togetter OAuth PKCEがRFC7636として発行されました。 | @_Nat Zone RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients 一言でいうと この規格はOAuth 2.0 [RFC6749]のPublic Client の Code Interception Attack 脆弱性に対応するもので、ephemeral keyを生成して、これを使ったProof of Possession of
OAuth & OpenID Connect 関連仕様まとめ - Qiita
はじめに OAuth や OpenID Connect に関連する仕様を紹介していこうと思います。 仕様はたくさんあるものの、ほとんどオプショナルです。しかし、「認可サーバーを実装する際は、RFC 6749 だけではなく、認可コード横取り攻撃への対抗策である RFC 7636 も実装すべきである」* という点は強調しておきたいと思います。 * 「PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと」という記事もご参照ください。 1. OAuth 2.0 (RFC 6749) OAuth 2.0 の仕様の本体は RFC 6749 (The OAuth 2.0 Authorization Framework) です。RFC 6749 の解説記事は世の中にたくさんあるので、ここでは要点だけ手短に紹介します。 RFC 6749 は、アクセストークンを発行
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
はじめに この文書では、OAuth 2.0 + OpenID Connect サーバーをゼロから一人で実装した開発者（私）が、得られた知見について書いていきます。基本的には「実装時に考慮すべき点」を延々と述べることになります。 そのため、この文書は、「素早く OAuth 2.0 + OpenID Connect サーバーを立てる方法」を探している方が読む類のものではありません。そのような情報をお求めの方は、「Authlete を使って超高速で OAuth 2.0 & Web API サーバーを立てる」を参照してください。そちらには、「何もない状態から認可サーバーとリソースサーバーを立て、アクセストークンの発行を受けて Web API をたたいて結果を得る」という作業を、所要時間 5 ～ 10 分でおこなう方法が紹介されています。 文書のバイアスについて 私は、OAuth 2.0 + Ope
OpenID Foundation Japan
公開資料 OpenIDファウンデーション・ジャパンでは、OpenID関連技術仕様の日本語訳や、プレゼンテーション資料、その他各種文書を公開しています。 技術仕様 OpenID Connect OpenID Connectは、OAuth 2.0をベースとする、シンプルなアイデンティティ連携プロトコルです。 ここでは日本語訳された仕様を紹介しています。原文ならびにその他の仕様については http://openid.net/connect/ をご参照ください。 OpenID Connect 1.0 specification OpenID Connect Core 1.0 日本語訳 OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである. このプロトコルは Client が Authorization Server
モバイルアプリのユーザ認証方法についてまとめてみた - Qiita
追記 (2018-10-08) 4年以上前に書いた記事ですが、Access Token として JWT を利用することは非推奨なようなので、お詫びして修正致します。 参考: どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ 概要 みんなやってるはずなんだけど、あまりまとまった情報がなかったので書いてみます。認証周りはセキュリティを気にして、みんな書きたがらないのかな？それとも私の調べ方が悪かっただけ？マサカリお待ちしてます。 認証の基本方針 +--------+ +--------+ | | | | | |----(1) Credential ------------>| | | | | | | |<---(2) Access Token -----------| | | | | | | Client | | Server | | | | | | |----(3)
[PHP] ライブラリに頼らないTwitterAPI入門 - Qiita
前書き 「ライブラリで何してんのか分からないから気持ち悪いんじゃヴォエエエ」 って人は読んでみるといいと思うよ（震え声） HTTP通信について全く知らない人は、先に以下のリンク先を読んでおいてください。 とほほのWWW入門 - HTTP入門 リクエストパラメータ・セッションに関するまとめ ※ HTTP通信における改行コードは全て \r\n です。 GET /1.1/statuses/show.json?id=464526017030545409 HTTP/1.1 Host: api.twitter.com Authorization: OAuth oauth_consumer_key="***", oauth_signature_method="HMAC-SHA1", oauth_timestamp="***", oauth_version="1.0a", oauth_nonce="***
![[PHP] ライブラリに頼らないTwitterAPI入門 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/ba079a99da56f814ece10c26452a27ebecb63d82/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCUEhQJTVEJTIwJUUzJTgzJUE5JUUzJTgyJUE0JUUzJTgzJTk2JUUzJTgzJUE5JUUzJTgzJUFBJUUzJTgxJUFCJUU5JUEwJUJDJUUzJTgyJTg5JUUzJTgxJUFBJUUzJTgxJTg0VHdpdHRlckFQSSVFNSU4NSVBNSVFOSU5NiU4MCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ODk0MjE0NWNlYTgwMTQ1YWU2OWU4YzE3OWQyYWIxYzI%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbXB5dyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ZTcxMDU2ZjgzMjg0YmM3ZWY2NDM1OThkMjkyNmU4Yzg%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D81c258c39f20c8291849436bc0bef203)
OAuth1.0の署名(Signature)を作成する方法
公開日: 2014/08/09 / 更新日: 2017/01/22 OAuth2.0が登場してからも、1.0を採用し続けるwebサービスはTwitter、Tumblr、500pxなど、まだまだ数多く残っています。今回はOAuth 1.0認証における署名(Signature)の作成方法を紹介します。なお、この記事で説明する署名の作成方式は「HMAC-SHA1」です。 OAuth1.0の署名とは？署名って何？署名とは、簡単に言うと、URLアドレスとパラメータ＋αを暗号化したものです。「OAuth1.0」という認証方式を採用したAPIを利用する場合、リクエストするパラメータに応じて、署名(Signature)となるキー(暗号)を作成し、一緒に送信しなければいけません。APIを提供するサービス側は、アプリケーション側が送ってきたパラメータと、この署名を照合し、署名が正しくない場合、エラーを返します
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
