IPA ISEC セキュア・プログラミング講座：Webアプリケーション編 第2章 アクセス制御
複数のWebアプリケーションがユーザ認証の機能を外部に一元化することによって、ユーザがパスワードを覚える負担を低減することができる。また、Webアプリケーションのオーナは、パーソナル情報の管理の負担とリスクを外部に転嫁することができる。 外部のユーザ認証サービスと連係動作するしくみ パスワードを用いたユーザ認証機能として、Webアプリケーションから利用可能な外部サービスが、2005年頃から提供されるようになってきた。 参考資料： 『アイデンティティ管理技術解説』 ユーザによるアクセス要求を遮断できるコードを開発して、そこから外部のユーザ認証サービスとアクセス認可判定の処理を順に呼び出すようにする。この要求を遮断できるコードは、PEP（Policy Enforcement Point）の役割を果たす。 ユーザ認証の結果をPEPに伝達するしくみとしては、「HTTPリダイレクト」の機能が応用され
OpenAMのOpenID Connectへの対応
連載目次 OpenAMが提供するフェデレーションサービス 第4回はOpenAMのOpenID Connectへの対応について紹介します。その前に、まずはOpenAMがこれまでに対応してきたフェデレーション（注1）プロトコルについて簡単に解説し、今後主流になると思われるOpenID Connectの概要とOpenAMの対応内容について説明します。 注1 フェデレーション（Federation）：異なるサービス間の連携をすること。一般的には、SAMLなどの標準的なプロトコルを使用して複数のクラウドサービスへSSOできるようにすることを意味します。 OpenAMが対応するフェデレーションプロトコル OpenAMは、あらゆるサービスへのSSOを実現できるように、これまで多くのフェデレーションプロトコルに対応してきました。SAML 1.0の実装から始まり、WS-Federation 1.1やID-F
OpenID Connectはそんなに大変かね？ - OAuth.jp
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita ってのになんかフォローアップしろよ的なのが来たので。 ざっと読んだ感想としては、「OpenID Connect の OPTIONAL な機能全部実装したら、そら大変ですね」という感じ。（Authlete に関しては、OpenAM みたいな感じで使われる、OpenAM よりはるかに簡単に使える代わりに有料の何かなんだろうな、というイメージです） OAuth は必要なのか？ Basic 認証は死んだ。 ユーザー単位での API のアクセスコントロールがしたいです。 っていう前提で話すると、OAuth 以外まともな選択肢が無いんじゃないでしょうか。 OAuth の各種 Extension (RFC 6749 & 6750 以外にいろいろある) に関しては、適宜必要なのを実装すればいいんだけど
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 は、アクセストークンを発行
Bearer Token とは？
► 2024 (23) ► 1月 (23) ► 2023 (2) ► 12月 (1) ► 6月 (1) ► 2022 (6) ► 12月 (1) ► 11月 (2) ► 10月 (1) ► 7月 (1) ► 2月 (1) ► 2021 (11) ► 12月 (2) ► 8月 (1) ► 7月 (2) ► 5月 (1) ► 4月 (2) ► 3月 (1) ► 1月 (2) ► 2020 (10) ► 12月 (1) ► 10月 (1) ► 9月 (2) ► 7月 (1) ► 6月 (1) ► 5月 (3) ► 4月 (1) ► 2019 (24) ► 12月 (1) ► 11月 (2) ► 10月 (1) ► 9月 (2) ► 8月 (1) ► 7月 (1) ► 6月 (7) ► 5月 (2) ► 4月 (2) ► 3月 (2) ► 2月 (2) ► 1月 (1) ► 2018 (35) ►
非技術者のためのOAuth認証(?)とOpenIDの違い入門【2023年版】
昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 Youtube版 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」（ユーザ認証）という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をして
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
