OCHaCafe Season4 #4の資料です． デモのソースコード等はこちらをご参照ください．
マイクロサービスの認証・認可とJWT / Authentication and Authorization in Microservices and JWT
OCHaCafe Season4 #4の資料です． デモのソースコード等はこちらをご参照ください．
Microservices における認証と認可の設計パターン
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
開発者はコアな機能の実装に集中できる！ Auth0が提供する認証・認可の最適解【デブサミ2019夏】
認証・認可はどんな種類のアプリケーションにも求められる機能だ。一方で、技術仕様が複雑で実装が困難な領域でもある。「仕様の調査に膨大な時間がかかった」「認証の実装方法に不備があり、アプリケーションに脆弱性を作ってしまった」といった経験を持つエンジニアは少なくないだろう。そうした課題を解決してくれるのが、Auth0株式会社が提供する認証・認可のプラットフォームである。多種多様な機能を有する同社のライブラリは、わずか数行のコードを記述するだけで利用可能だというから驚きだ。同社ソリューションズエンジニアの山口央氏が、Auth0のサービスを用いて認証・認可の課題を解決する方法を解説した。 講演資料：ソフトウェア開発における認証・認可の位置付けと課題、現実解を探るアプローチ Auth0株式会社 ソリューションズエンジニア 山口央氏 認証・認可を外部サービスでまかなうことの利点 現代は、数多くのアプリケ
OAuth 2.0 クライアント認証 - Qiita
はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。
認証と認可 - Qiita
行動やリソースの使用を許可すること。 「伺っております。奥へどうぞ」 もともと 認可 = 認証 で長いこと来ていた。 認証 = 認可 の時代 認可は「玄関を開けて中へ入る」ことに例えることができる。 「鍵」を持っている人間は「玄関を開けて中へ入る」ことができる。これは明らかに行動の許可。なので、認可だ。 (この「鍵」とはつまりIDとパスワード、またはそれに類するもろもろのことだ) 周囲の知らない人間からすれば、家の鍵を開けて入る人間はまあその家の人間だろう、としか思われない。これが 認可 = 認証 の時代である。 しかし、様々なサービスが普及するとこの「鍵」が増えすぎるという事態が発生した。鍵束がジャラジャラして邪魔になったようなものである。 単に邪魔なだけならまだしも、管理が行き届かなくなるのは自明である。 また横着して同じ「鍵」を使い回すことも行われるようになった。これはセキュリティ上
よくわかる認証と認可 | 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: 都元、日頃のお
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
