単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット＆ペーストアタックが可能だからです。 OAuth 認証？は、図１のような流れになります。 図１ OAuth 認証？の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A
OAuth 2.0 の仕組みと認証方法
OAuth 2.0 の仕組みと認証方法について説明します。OAuth 1.0 の認証フローとそれらの問題点から、OAuth 2.0 の認証フロー、認可コード、アクセストークン、リフレッシュトークンまで網羅します。
[deprecated] omniauth-openid-connect 'renewed' | Netsphere Laboratories
重要． このソフトウェアは、もはやメンテナンスされていません。 OmniAuth ライブラリは何らかの認証フレームワークと組み合わせます。OpenId Connect を実装するとき、OmniAuth ストラテジとして実装しなくても、認証フレームワーク上で作ってやればよい。OmniAuth はもはや不要。 Sorcery をお勧めします。Digital Identity 技術 OmniAuth (Ruby) 用の OpenID Connect ストラテジ。このパッケージは次のパッケージを置き換えます。 omniauth-google-oauth2 omniauth-yahoojp omniauth-azure-oauth2 omniauth-azure-adv2 omniauth-line omniauth-line-openid-connect omniauth-salesforce オ
OAuth 2.0の代表的な利用パターンを仕様から理解しよう
連載 INDEX 次回 → はじめまして、OpenID Foundation Japan事務局長のNovです。 このたびは、Build InsiderでOAuth 2.0とOpenID Connectに関する記事を書かせていただくことになりました。 今回はOAuth 2.0、次回はOpenID Connectについて、ユースケースごとのフロー（Flow）や関連仕様についてまとめていきます。 OAuth 2.0仕様策定から5年 OAuth 2.0はIETF OAuth WG*1で仕様策定されている標準仕様群である。 最もコアとなるRFC 6749＆RFC 6750はどちらも2012年にRFC化されており、すでに策定から5年以上が経過している。OpenID Foundation Japanの翻訳WGでもこれらは翻訳済みである。 The OAuth 2.0 Authorization Frame
AWS REST リクエストの署名についてメモ
AWS の REST API のリクエストでは署名(signature)を使って、API のセキュリティチェックを行っている。 サービス開始時に Version 1(いまは使われていない) が公開されたあと、2, 3, 4 という合計4種類が存在する。 この署名の仕様をメモ。 version 1 最も古い Version 1 ?Action=CreateQueue &QueueName=queue2 &AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE &SignatureVersion=1 &Expires=2007-01-12T12:00:00Z &Version=2006-04-01 というような PARAM=VALUE がずらずらと並んだ GET リクエストを考える。 STEP1 パラメーターを大文字/小文字を無視して辞書順にソート。 ?Action=Creat
改めて知ろう、SSLサーバー証明書とは？（第二回） | さくらのナレッジ
こんにちは、サイバートラストの坂本です。前回に続き、入門編として、SSL サーバー証明書について説明致します。 SSLサーバー証明書の違い 前回の記事では、SSL サーバー証明書に関する動向は、今年も来年も目が離せないといった状況をふまえ、改めてSSL を理解しておこうという目的のため、証明書の役割である暗号化と認証について説明しました。また、その記事のなかで、認証のレベルには違いがあることを言及しました。 SSL サーバー証明書の種類は 3 つに分けられるのですが、それは、暗号の強さ（どれだけ破られにくいか）で分類されるのでなく、どこまで詳しく証明書の名義の人（組織）を調べるかという認証のレベルによって分けられるのです。 今回は、この認証の違いについて説明させてください。 DV、OV、EV 認証レベルの違いにより、証明書の呼び方が異なります。業界では、Domain Validation
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
総務省 電波利用ホームページ｜電波監視｜技適マークのＱ＆Ａ