OAuth2.0で認可コードの漏洩を防ぐPKCE - 理系学生日記
OAuth 2.0 における通信は基本的に TLS で守られるのが基本なのだけれど、ひとつ TLS で守られない通信があります。それは Client・User-Agent 間の通信です。 Authorization Code Grant においては、認可サーバから認可コードを受けた User-Agent がその情報をクライアントに渡すときに発生します。 Authlete via kwout Authlete さんの以下の図がすごくわかりやすいのですが、User-Agent (Operation System Browser) から Malicious App に認可コードが漏れていることがわかります。 Native App では、これは Custom Scheme が悪意のある App に上書きされた場合等で発生します。 もちろん、認可コードが漏れたら、アクセストークンも漏れるので、このよ
OAuth 2.0 におけるアクセストークン実装方法の検討 - 理系学生日記
OAuth 2.0 のプロバイダにおいて、アクセストークンをどのようにシステムで保持するのかっていうところを考えたり調べたりしていました。 前提として、OAuth のトークンには以下の 2 種類の表現方法があります (RFC 6819 3.1. Tokens) Handle "opaque" トークンとも呼ばれるトークンの表現方法です。 認可サーバー内部のデータ実体に対する単なる参照として表現され、トークンの文字列自体に意味はありません。トークンから参照を得るためには、トークンをキーにデータ実体を探して、必要な情報 (DB 上とかにある有効期限とか) を手に入れるという形になります。 Assertion トークン自体に意味を持たせるトークンの表現方法です。 トークンから直接、必要な情報 (有効期限とか) を取得できます。 アクセストークンに焦点を合わせると、トークンを発行するのは認可サーバ
HashiCorp社が出したVaultとはどういうものなのか - 理系学生日記
HashiCorp 社から、新たなソフトウェアである Vault by HashiCorp がリリースされました。 - HashiCorp Blog: Vault この Vault について、Getting Started を一通り実施した後に Docs の一部を確認してみたので、簡単にその内容をまとめてみます。 Vault とは何なのか Vault を一言で言うと、機密情報(Secret) を管理するツールです。 これだけ IT が広がっている現在、機密情報の範囲も広がり続けており、データベースにアクセスするためのユーザ/パスワードや、連携するシステムの API キー等、多岐に渡ります。こういった情報、おまえのところのシステムではどう管理してた？XML に生で書いてる、あるよねそういうの。jdbc.properties に直書き、うんうんわかるわかる。ちょっとがんばったら crypt で
POST をリダイレクトすると GET になる件について調べた - 理系学生日記
とある事情により、POST リクエストをリダイレクトさせる必要が生じました。単純にリダイレクトさせてみたところ、リダイレクトはされるものの、POST リクエストに付与していた HTTP_BODY が取得できません。どうも、リダイレクト時に GET に変更されているみたいです。 ぼくは怒りに震えたものの、RFC 的にはどう振る舞うべきなんだ、各種ブラウザの振舞いはどうなっているんだ、ということが気になったのでまとめてみました。内容としては、 -POSTリクエストをリダイレクトするとGETされる？POSTされる? - はこべにっき ♨ の二番煎じになります。 先に結果を示しておくと、以下のとおりでした。 Status Code 期待動作 Firefox (25.0.1) Safari(7.0) Chrome (31.0) 301 POST GET GET GET 302 POST GET GE
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
