OAuth 2.0 各社の仕様まとめ - QiitaOAuth 2.0を利用したAPIを提供している各社サービスの気になる仕様をまとめました。 具体的には、ドキュメントやリクエストのURL、scopeの形、アクセストークンの有効期限、RFCで指定されていないオリジナルのパラメータなどです。RFCは自由度が高いので、どのように実装しているのか気になりますね👀 追加したい項目や修正など、編集リクエスト/コメントお願いします！ GitHub OAuth Apps グラントタイプ: Authorization Code Grant 用途 URL
図解 DPoP (OAuth アクセストークンのセキュリティ向上策の一つ) - Qiita
はじめに DPoP（ディーポップ）という仕様を紹介します。 OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP) この仕様は、悪い人がアクセストークンを盗んだとしても、それだけでは API に対する不正アクセスができないようにするための仕組みです。 従来は、クライアントアプリケーションがアクセストークンを提示して API にアクセスしてきたとき、そのアクセストークンが有効であれば、API アクセスは許可されていました。しかし、DPoP などの Proof of Possession（PoP）の仕組みを用いると、アクセストークンを提示しているクライアントがそのアクセストークンの正当な所有者かどうか（＝アクセストークンの発行を受けたクライアントと同一かどうか）もチェックされるようになり、アク
Microservices における認証と認可の設計パターン
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
認証プラットフォーム Auth0 とは？ - Qiita
2017/06/28にドコモベンチャーズがAuth0に出資をしたというニュースが流れましたが、Auth0とはどんな会社で、どんなサービスを提供していのでしょうか？ Auth0とは Auth0 Inc.は2013年に米国Microsoftに在籍していたメンバーを中心に創業した会社で、Washington州Bellevueに本社があります。創業メンバーはEugenio Pace(CEO), Matias Woloski(CTO) などMicrosoftに在籍していたメンバーのほか、Node.jsの認証フレームワークである"Passport"の開発者であった Jered Hanson, AT&T, Amazon.com, 国防総省での勤務経験のある Eugen Koganも創業メンバーです。 Auth0 統合認証プラットフォーム Auth0はWebアプリやモバイル、APIなどに対して認証・認可の
マイクロサービスでの認証認可 - Qiita
複数のクラウドサービスを利用している（マルチクラウド）など、単純には閉域網を構築できない環境でマイクロサービスアーキテクチャを採用する場合には、サービス間の認証認可が必要となる。この場合のサービス間の認証認可方式を決める参考となる、OSSやSaaS、Webサービスで採用方式ついて整理した。 Istio サービスメッシュの実装として有名なIstioではサービス間通信を以下のように制御できる。 Istioの認証認可では認証主体がService Identityというモデルで抽象化され、KubernatesやIstioで定義するService Accountに加えて、GCP/AWSのIAMアカウントやオンプレミスの既存IDなどをService Identityとして扱うことができる。 サービス間の認証 (Peer Authentication) は、各サービス (Pod) に設置するSideca
30分でOpenID Connect完全に理解したと言えるようになる勉強会
社内向け勉強会で発表した内容です。 30分でと書いてありますが、実際には50分かかりました。 また時間の関係で結構省いたりしている箇所があります。 2020/07/19追記 ご指摘をいただいた箇所を多々修正いたしました。 特にOIDCとSPAの章が初版とは大幅に変更されていますのでご注意く…
JWT を使った 2-legged-OAuth で Box Content API の認証・認可を行う ｜ Tips Note by TAM
2016.04.01 JWT を使った 2-legged-OAuth で Box Content API の認証・認可を行う はじめに こんにちは。フロントエンドエンジニアの安部です。 プリズムの煌めき、浴びましたか？ 私は浴びました。 さて、今回は2-legged OAuthと呼ばれる認可プロセスを使って、コンテンツプラットフォームであるBox（box.com）のWeb APIであるContent APIを使用してみます。 Boxとは？ クラウドプラットフォームのひとつで、書類や画像などのファイルを管理・共有・コラボレーションするサービスです（Box Japan公式サイト）。 エンタープライズ用Dropboxと考えるとわかりやすいですかね。 Content APIとは？ BoxのコンテンツやユーザをRESTfulなAPIでWebインターフェースと同様にリソース操作が出来るWeb APIで
『いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい』の予習・復習用情報 - Qiita
はじめに Authlete（オースリート）社主催の勉強会『いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい』（2020 年 1 月 31 日（済）, 2020 年 2 月 21 日（中止））の内容がてんこ盛り過ぎるため、予習・復習用の情報を書き出そうと思います。 追記 2020 年 1 月 31 日の勉強会の資料と動画（字幕付き）を公開しました！ OAuth / OIDC 勉強会参加者は、OAuth 2.0（オーオース）と OpenID Connect（オープンアイディー・コネクト）の基本を知っていることが前提となります。 OAuth 2.0 は「アクセストークンを発行する仕組み」です。その中心となる仕様は RFC 6749 です。詳細については『一番分かりやすい OAuth の説明』と『OAuth 2.0 全フローの図解と動画』をご参照ください。 Op
【JWT】 入門 - Qiita
JWTとは 公式サイト JSON Web Tokenの略 電子署名により、改ざん検知できる。 認証用のトークンなどで用いられる。 構成 ヘッダ、ペイロード、署名の3つから成る。 それぞれは、Base64でエンコードされている それぞれは、 . (ドット) で結合されている。
マイクロサービスにおける内部通信の認証について
"Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~"の発表資料です。 https://connpass.com/event/142624/
Microsoft ID プラットフォームのアプリケーションの種類 - Microsoft identity platform
Microsoft ID プラットフォームでは、さまざまな最新アプリ アーキテクチャ向けの認証がサポートされています。そのいずれも、業界標準のプロトコルである OAuth 2.0 または OpenID Connect に基づいています。 この記事では、使用する言語やプラットフォームを問わず、Microsoft ID プラットフォームを使用して作成できるアプリの種類について説明します。 情報は、アプリケーションのシナリオでコードを詳しく確認する前に大まかなシナリオを理解するうえで役立ちます。 基本 Microsoft ID プラットフォームを使用する各アプリを、Microsoft Entra 管理センターの [アプリの登録] で登録する必要があります。 アプリの登録プロセスでは、次の値が収集され、対象のアプリに割り当てられます。 アプリを一意に識別する アプリケーション (クライアント) I
マイクロサービス時代のSSOを実現する「Keycloak」とは
本連載では、近年注目されている認証プロトコル「OpenID Connect」をサポートするオープンソースのシングルサインオン（SSO）ソフトウェア「Keycloak」の活用方法を解説していきます。第1回目は、APIにおける認証／認可の仕組みとKeycloakの概要を紹介します。 連載目次 APIにおける認証／認可の仕組み 近年、金融や流通分野で注目されている「APIエコノミー」や「マイクロサービスアーキテクチャ」などの登場により、サービスの機能を「REST API」として提供することが当たり前になってきています。そして、REST APIを公開するためには、誰がアクセスしてきたのかを確認するための「認証（Authentication）」と、APIへのアクセスを誰に許可するのかという「認可（Authorization）」の仕組みが不可欠です。 しかし、複数のサービスがそれぞれ個別に認証／許可を
金融 API 時代のセキュリティ: �OpenID Financial API (FAPI) WG
タイトル： 『認証の課題とID連携の実装 �〜ハンズオン〜』 概要： FIDO、ID連携（OAuth・OpenID Connect）をはじめとした最近の技術をご紹介します。FIDOは端末とサーバー間でユーザー認証を安全に連携するための仕組みです。OpenID Connectはユーザーの認証と認可を連携するためのID連携の仕組みで、OAuth 2.0を拡張した仕様であり、HTTP通信やJSONなど基礎的なWeb技術によって構成されています。FIDOとID連携の技術を学んだ後、実習ではGolangを用いてWebアプリケーション上にOpenID Connectを実装します。実装の注意点とそのリスク、仕様に施されているセキュリティー対策についてハンズオンを行いながら解説します。 セキュリティ・キャンプ全国大会2019 専門講義 選択コース B4 認証の課題とID連携の実装 〜ハンズオン〜 Aug
OAuth 2.0/OpenID Connectの2つのトークンの使いみち - Qiita
はじめに 最近、Amazon CognitoとAPI Gatewayを少し触る機会があり、そこでOpenID ConnectのIDトークンを使ったAPI Gatewayでのアクセスコントロールができることを知りました。Cognitoの 開発者ガイド >> Amazon Cognitoユーザープール >> ユーザープールのトークンの使用には下記のように書かれています。 ID トークンを使用する ID トークンは JSON Web キートークン (JWT) として表されます。トークンには、認証ユーザーの ID に関するクレームが含まれます。たとえば、name、family_name、phone_number などのトークンが含まれます。標準クレームに関する詳細については、OpenID Connect specification を参照してください。クライアントアプリは、アプリケーション内でこの
一番分かりやすい OpenID Connect の説明 - Qiita
はじめに 過去三年間、技術者ではない方々に OpenID Connect（オープンアイディー・コネクト）の説明を繰り返してきました※1。 その結果、OpenID Connect をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。 2017 年 10 月 23 日：『OpenID Connect 全フロー解説』という記事も公開したので、そちらもご参照ください。 説明手順 （１）「こんにちは！ 鈴木一朗です！」 （２）「え！？ 本当ですか？ 証明してください。」 （３）「はい！ これが私の名刺です！
Azure Active Directory で Spring Boot and OAuth2 - Azureの小ネタ （改）
追記 2017/07/12 少しきれいにしたサンプルを以下に置いてあります。 github.com Sprint Boot and OAuth2 ということで、以下にチュートリアルがあったりするわけですが、チュートリアルには、FaceBookとGithubの例が載っていたので、ふと思い立ってAzure Active Directoryでも出来るのか試してみました。結論からいうとできたのですが、全てを理解してやっているわけではないのでご注意を。もっとスマートな方法があるのではないかと思ってます。 spring.io チュートリアル内にはいくつかサンプルがありますが、基本同じ様なことをちょっとづつ変えて試すような流れになっているぽいです。 click: adds an explicit link that the user has to click to login. の中で↑のようなやつを少
OAuth 2.0 全フローの図解と動画 - Qiita
RFC 6749 (The OAuth 2.0 Authorization Framework) で定義されている 4 つの認可フロー、および、リフレッシュトークンを用いてアクセストークンの再発行を受けるフローの図解及び動画です。動画は YouTube へのリンクとなっています。 English version: Diagrams And Movies Of All The OAuth 2.0 Flows 追記 (2019-07-02) 認可決定エンドポイントからクライアントに認可コードやアクセストークンを渡す方法については、別記事『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』で解説していますので、ご参照ください。 追記（2020-03-20） この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！ 1. 認可コードフロー RF
OAuth 2.0のAccess TokenへのJSON Web Token(JSON Web Signature)の適用 - r-weblife
こんばんは、ritouです。 久々の投稿な気がしますが、今回はOAuth 2.0のリソースアクセス時の設計の話です。 ずーっと前から書こうと思いつつ書いてなかったので、ここに書いておきます。 出てくる用語や仕様は、下記の翻訳リンクを参照してください。 The OAuth 2.0 Authorization Framework JSON Web Signature (JWS) 想定する環境 わりとよくある環境を想定しています。 OAuth 2.0で認可サーバーとリソースサーバーがある 認可サーバーがAccess Tokenを発行 リソースサーバーがAPIリクエストに含まれるAccess Tokenを検証する よくある実装とその悩みどころを、JSON Web Token(JSON Web Signature)により軽減できるかもという話です。 よくある実装 : Access Tokenに一見ラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Auth0：誰もが安全にアクセスするために。でも、誰でもというわけではありません。
Advanced Microservices Security with Spring and OAuth2 - DZone