Authorization
commited date: 2025-03-22
-
APIゲートウェイ#API Architecture #Network 外部トラフィックに対してリバースプロキシ・ロードバランシングが持つようなネットワークのルーティング・セキュリティと可用性の向上に加え、以下のような機能横断的な要件を扱う役割 認証 認可 レートリミット リトライ サーキットブレーカー etc.
-
OAuth徹底入門
-
マスタリングAPIアーキテクチャ
-
RBACRole-based access control #Security #Authorization ロールごとに許可を定義する認可モデル これによりユーザーの部署異動等の際に即座に権限を変更できる
-
Bearerトークン#Security #Authorization トークンを保持するBearer(持参人)が誰であれ、そのトークンをリソースへのアクセスに使うことができる 平文の文字列でシークレットや署名は扱わず、セキュリティはTLSのようなトランスポート層での仕組みに任せている HTTP通信のAuthorizationヘッダーに付与するのを推奨されている RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
-
OIDC
-
AuthorizationPolicy#Security #Authorization Istioにおいてアプリケーション(OSI参照モデルのL7レイヤ)認可の役割を担うリソース KubernetesのCustomResourceDefinitionによって用意されており、Network policyに比べ柔軟でHTTP特有の設定が可能 Istio / Authorization Policy
-
Kubernetes/ClusterRole
-
Kubernetes/ServiceAccount
-
Kubernetes/RoleBinding
-
Kubernetes/Role
-
Kubernetes/ClusterRoleBinding
-
コンプリケイテッド・サブシステムチーム#Team Organization チームトポロジーにて紹介される4つのチームタイプの内の1つ 認証や認可・決済等のサブシステムを構築しストリームアラインドチームにAPIを提供する
-
ABACAttiribute-based access control #Security #Authorization 従来のRBACに対し、リソースに割り当てられた属性(AWSではタグ)に基づいて許可を定義する認可モデル リクエスト元であるプリンシパルの属性がリソースの属性と一致した場合に操作を許可するポリシーを設計する ABAC 認証で属性に基づいてアクセス許可を定義する - AWS Identity and Access Management
-
Authorization to implement with Extensible Effect#Security #Programming #Authorization EffによるScala認可実装の話
-
OAuth2#Security #API Architecture #Authorization RFC6749によって定義された認可フレームワーク 主に以下の定義を利用する リソースオーナー(Resource Owner) 保護されたリソースへのアクセス許可を行うエンドユーザー リソースサーバー(Resource Server) 保護されたリソースを所有するサーバー、アクセストークンを受け取り検証する クライアント(Client) リソースオーナーによる認可の委譲先、アクセストークンを使ってリソースサーバーへリクエスト可能 認可サーバー(Authorization Server) リソースオーナーの認証・アクセス許可時に認可グランドを返却したのち、クライアントにアクセストークンを発行する 初回アクセストークン利用までのプロトコルの流れは以下 Protocol Flow リソースオーナーによるアクセス許可時に認可サーバーが返す認可グランドは、認可コードが利用されることが多い RFC 6749 - The OAuth 2.0 Authorization Framework