タグ

ブックマーク / oauth.jp (7)

  • JSON Web Token (JWT) - OAuth.jp

    @novです。 個人的に最近OAuth 2.0よりJWT (というかJWS) を利用するシーンが多く、毎回同じ説明するのもめんどくさいのでブログにまとめるかと思い、どうせならOAuth.jpに書くかということで、こんな記事を書いております。 （そろそろJWTとJWSは、OpenID Foundation Japanの翻訳WGで翻訳するべき？） JSON Web Token (JWT) とは、JSONをトークン化する仕組み。 元々はJSONデータにSignatureをつけたりEncryptionする仕組みとして考えられたものの、Signature部分がJSON Web Signatue (JWS)、Encryption部分がJSON Web Encryption (JWE) という仕様に分割された。 それぞれ2012年10月26日現在の最新仕様はこちら。 （JWTとJWSは既にだいぶ仕様が固

  • Y!J API が止まった日 - GlobalSign の Root 証明書切れから学んだこと - OAuth.jp

    昨日あたりから、Yahoo! Wallet や YConnect といった、Yahoo! Japan の API にアクセスできなくなったって人、ちらほらいるかもしれませんね。 僕もちょっとそういうケース見かけました。 なんか Yahoo! Japan がポカしちゃったの？とか、まぁ昨日まで健康に動いてたシステムが突然 Yahoo! Japan の API にアクセスできなくなっちゃったんだし、そらそう思うのもムリはない。 が、今回のケース、Yahoo! は全く悪くない！ プライバシーフリークはどうかと思うがな！！ では早速、今回起こったことを、振り返ってみましょう。 Yahoo! API にアクセスできなくなった Yahoo! Japan は、yahoo.co.jp 以外にも、CDN 用や API 用など、用途ごとにいくつかのドメインを持ってます。 今回止まったのは、その中の API 用

  • Rails SessionにCookieStore使った時の問題点 - OAuth.jp

    今日 @mad_p さんからRT来てたこのツイートに関して、ちょっと調べたのでまとめときます。 Security Issue in Ruby on Rails Could Expose Cookies http://t.co/JlsXVEn4rZ — Ruby on Rails News (@RubyonRailsNews) September 25, 2013 前提条件 Railsではデフォルトでsessionをcookieにのみ保存して、DBなりmemcacheなりのserver-side storageには何も保存しません。 これがCookieStoreとか呼ばれてるやつです。 この場合のsession cookieは、Railsのsession object (Hash object) をMarshal.dumpしてそれに署名を付けたtokenです。 rails 4では署名付ける代

  • https://oauth.jp/post/43684099914/json-web-token-jwt/

  • OAuth.jp

    いままで Mix-up Attack は Client が AS 毎に redirect_uri を使い分けていれば防げると信じられてきましたが、それじゃ防げないケースもあるよってのが OAuth ML に投稿されました。 細かい解説は英語読んでもらうとして、シーケンスにするとこういうことです。 Attacker AS が (Display Name やロゴ等を通じて) 一見 Honest Client に見えるような Client (Attacker Client) を Honest AS に登録しておく必要があります。 User が Attacker AS 選んでるのに Honest AS に飛んで Approve してしまってる部分も、Attacker Proxy が利用可能な状況 (e.g., Client が HTTP なエンドポイントで Honest AS のログインボタン等を

  • OAuthのoffline_accessについて - OAuth.jp

    少し前ですが、OpenID Connectのbitbuckeetでoffline_accessについての議論がされていたので、まとめておきます。 Googleの場合 offline access の定義 refresh tokenが発行されるのがoffline。 特にoffline accessを要求しない限り、デフォルトではonline accessを要求したものと見なされる。 online accessの場合はrefresh tokenは発行されない。 refresh tokenはユーザーがrevokeするまで有効。 auto approval 一度ApproveされたClientに対しては、accessがrevokeされるまでは次回以降のAuthorization Request時の同意画面はスキップされる。 同意画面がスキップされる場合、refresh tokenは発行されない。

  • Re: OAuth 2.0のclient_secretって本当に秘密鍵ですか？ - OAuth.jp

    昨日こんな記事を見かけたので、記事にまとめることにします。 OAuth2.0のclient_secretって本当に秘密鍵ですか？ 元記事にあるとおり、現状Native AppでのOAuth 2.0の実装は、API提供者・利用者ともにポリシーがバラバラで、混乱の元になっていると思います。 Googleのドキュメントにも「the client_secret is obviously not treated as a secret.」とあるわけだけど、そのくせclient_secretを使ってるし、ネットで調べても少なくない数の人がアプリに埋め込んでるので、client_secretを公開したときの問題を考えてみる。 "offline" アクセスと "online" アクセス Googleは、"offline access" に対して以下のようなポリシーを持っています。 Upcoming cha

  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.