OCHaCafe Season4 #4の資料です． デモのソースコード等はこちらをご参照ください．
マイクロサービスの認証・認可とJWT / Authentication and Authorization in Microservices and JWT
OCHaCafe Season4 #4の資料です． デモのソースコード等はこちらをご参照ください．
OAuth 2.0 クライアント認証 - Qiita
はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。
よくわかる認証と認可 | DevelopersIO
よく訓練されたアップル信者、都元です。「認証 認可」でググると保育園の話が山程出て来ます。が、今日は保育園の話ではありません。そちらを期待した方はごめんなさい。こちらからお帰りください。 さて、先日のDevelopers.IO 2016において、マイクロWebアプリケーションというテーマでお話させて頂きました。一言で言うと OAuth 2.0 と OpenID Connect 1.0 のお話だったのですが、これらを理解するにあたっては「認証」と「認可」をはっきりと別のものとしてクッキリと認識する必要があります。 まず、ざっくりとした理解 認証と認可は密接に絡み合っている一方で全く別の概念です。正直、理解は簡単ではないと思います。 まず「認証」は英語では Authentication と言います。長いので略して AuthN と書いたりすることもあります。意味としては 通信の相手が誰（何）であ
AWS Dev Day Tokyo 2018 で「マイクロサービス時代の認証と認可」の話をしてきた #AWSDevDay | DevelopersIO
緊張すると声がヤムチャになる都元です。このセッションの自己紹介でアムロ・レイとか言って盛大にスベったので切り替えていきます！ さて、1週間の時間が経ってしまいましたが、去る 11/2 (金) に目黒セントラルスクエアにおいて「マイクロサービス時代の認証と認可」と題しましてお話をさせていただきました。 スライド 認証と認可の基礎知識 繰り返しになりますので、過去エントリーよくわかる認証と認可 ｜ DevelopersIO を参照してください。 また、Web API のアクセス制御としては、だいたい次の4つくらいが頭に浮かぶと思います。 Basic 認証 Digest 認証 リクエスト署名 OAuth 2.0 この辺りは Spring Day 2016 - Web API アクセス制御の最適解でお話したことがありますので、こちらも併せてご覧ください。 Coffee break: 都元、日頃のお
OAuth 2.0 / OIDC 実装の新アーキテクチャー - Qiita
1.『On-Premises』パターンは、自分でマシンを用意し、そこに認可サーバーのソフトウェアをインストールして運用する方法です。 2.『Hosted Server』パターンは、マシンの物理的な運用はクラウドサービスにまかせ、そのマシン上に認可サーバーのソフトウェアをインストールして運用する方法です。 例えば AWS の EC2 インスタンスに OpenAM をインストールして運用する場合、このパターンに該当します。 3.『Hosted Service』パターンは、認可サーバー自体がクラウドサービスとして提供されるパターンです。 Okta や Auth0 がこのパターンに該当します。 4.『Semi-Hosted Service』パターンは、認可サーバーの主要機能を提供するサーバーが存在するものの、一部をローカルで実装するというパターンです。 Richer 氏が明示的に言及しているように
インフラエンジニアが一切コードを書かずにWebサーバーに認証機能を実装した話 ｜ Developers.IO
コンニチハ、千葉です。 AWSのサービスを組み合わせれば、独自の認証基盤を構築できます。例えば、WordPressを限定的に公開する、Apache、 Nginx、カスタムWebアプリなどなど、簡単に認証をかけたい場合、ベーシック認証は昔から利用されてきました。ただし、これはスケーラビリティや運用面でどうしてもつらい場面がでてきます。 そこで、ALBに素敵すぎる組み込みの認証機能が追加されたのでこちらを利用し、コードを一切書かずに認証を導入します。また、OIDCなど認証プロトコルに対応していますが、今回はシンプルにCognitoのユーザープールを利用し、ユーザー管理自体もCognitoに任せます。 要件 今回の想定する要件です。 Nginxを社内ユーザーのみに公開 スタンドアローンのユーザープールを用意(AD、OICD、SAMLなどによる連携なしで、独自でユーザーを管理) ユーザーは管理者が
OAuth2.0サーバを素早く立てるライブラリ・フレームワークまとめ | NTT Communications Developer Portal
認証を行うAPIとしてはOpenIDが有名なのですが、認証だけであるためにメールアドレスの取得であったり、その後のシステム連携に繋げられないといった不満があります。そこで認証と委譲を行うOAuth（特に1.0の問題点を解決したOAuth2）を使うのが一般的になっています。 そこで今回は既存のシステムはもちろん、今後作られるシステムでも手軽にOAuth2の機能が追加できるライブラリを紹介します。 PHP bshaffer/oauth2-server-php 特に依存のないOAuth2サーバです。既存システムと並列して疎結合で立てるのが良さそうです。 thephpleague/oauth2-server こちらも独立型ですが、CakePHP3やLaravelとの連携も想定されています。 lucadegasperi/oauth2-server-laravel Laravelフレームワーク用のOA
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - IdentityServer/IdentityServer4: OpenID Connect and OAuth 2.0 Framework for ASP.NET Core