![Web Security Basics - An Introduction to the Essential Concepts Behind a Secure Website](https://cdn-ak-scissors.b.st-hatena.com/image/square/e9124510218d3b0645acae0f133429ab22134989/height=288;version=1;width=512/https%3A%2F%2Fwww.sohamkamani.com%2Fstatic%2F01e3b318ccf5c0d634aa5a789b16a67a%2Fbanner.png)
ふとAccessTokenを安全に扱うための方法について調べていて、最近 Proof of Possession というドラフトが 出ていることを知ったので、それについて簡単なメモ。 注.) このブログを書いた時点では各ドキュメントのドラフト番号が1とか2とかなので、今後大きく変わる可能性があります。 注.) まだ隅々まで読めているわけではないので、解釈の間違いなどがあるかもしれません。間違いがあった場合にはご指摘していただけると嬉しいです。 ID Token x Access Token では、Access Token 文字列が改ざんされていないことは確認できるが、Access Token が 漏えいした場合、それを確認する方法がない。 Proof of Possession で誰が(どの認可サーバが)誰に(どのクライアントに対して)発行した Access Token なのかを確認するこ
記事はFringe81 アドベントカレンダー2017の15日目です。 2日目担当のk315k1010さんからplay2-authの移行話を振られましたが、それは別の機会にとっておき、本記事ではJWT(JSON Web Token)を利用したWebアプリケーションの認証について記載したいと思います。 JWT(JSON Web Token)とは? JWTの詳細については世に多くの記事が既にある為、ここでは簡易に説明したいと思います。 一般的にセッションIDとCookieを利用した認証のフローは下記のようなイメージになるかと思います。 サーバサイド側でSession IDをKVS等に保存する必要が出てきますが、JWTを利用すれば認証した情報について、クライアントサイドだけで完結することができます。 JSONの形で表した情報をURLEncodeし、tokenとしてクライアントサイドにおくり、認証が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く