サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
ritou です。 一日遅れましたが、アドカレ最終日の記事です。 qiita.com 一個誰かが忘れてる以外は埋まってますね！特に中盤までのAuthlete無双ありがとうございます。 前日(24日)の記事も大作でございました。zenn.dev 今回は巷でよく言われている「OAuthは認可、OIDCは認証」ってフレーズについて整理しましょう。 「OAuthは認可」わかる OAuthは(最近だと3rdパーティーに関わらず)あるアプリケーションに対して安全なリソースアクセスの提供を実現するための仕様です。 リソースオーナーはそのアプリケーション自身かもしれないし、アプリケーションのユーザーかもしれません。 リソースアクセスを提供する側が認可し、利用する側は認可されてリソースアクセスをします。これは特に問題ないでしょう。 「OIDCは認証」わかる？ OIDCは認証、これはどういう意味かわかります
こんにちは。本記事では、アプリケーションの権限制御の実装でよく用いられる権限モデルと、それらの違いや使い所についてまとめます。 想定読者 権限モデルの種類や概要を知りたい方 RBACは実装したことがあるが、ABACは実装したことがなく、何となくだけ知っている方 ReBACは全く知らなかったのでとりあえず概要を知りたい方 →私です 前提 アプリケーションの権限制御とは、「アプリケーションが管理するリソースに対して、ある主体が行う何らかの操作を許可するか否かを判定する制御」だと考えます。 主体はユーザー単体であることもあれば、グループという形でユーザーの集合である場合もあります。 ECサイトを例にすると、以下のようなケースが考えられます。 顧客は自身の注文情報を閲覧することは許可されるが、他の顧客の注文情報を閲覧することは拒否される 顧客が商品を購入することは許可されるが、商品を作成すること
概要 やりたいことAuth0を用いたアプリケーション、正しくはAPIでユーザー毎にできることを切り分けたい。 ユーザーを管理者(admin)と通常メンバー(ordinary-member)に分けて管理したい。 このような管理をRBAC (Role-Based Access Control)と呼ぶらしい。 例えば、Auth0に ordinary-memberに設定された者は、メンバー情報の（一覧）取得と更新ができる。admin に設定された者 は、加えてメンバー情報の作成と削除ができるなど。 これらの設定はAuth0の管理画面からおこなうことができます。 RBACを使用できるようにする 管理画面のApplications →APIs に[+CreateAPI]で追加済の当該APIのSettingsを開きます。以下の両方のトグルスイッチをONにします。Enable RBACIf thi
https://aiau.connpass.com/event/365588/
English 2025年7月現在、MCPは2024-11-05、2025-03-26、2025-06-18の3つのバージョンを経て進化し、私達は手元のMCPクライアントとなるCursorやClaude CodeやVSCodeからnpxコマンドやuvコマンドやDockerコンテナによってMCPサーバーを起動したりRemote MCPサーバーに接続するなど日常的に使うようになりました。 実際に私自身がよく利用しているMCPライブラリであるMCP Servers - Cursorを見てみると多くのサービスが独自にMCPサーバーの提供に投資している様子が伺え、エコシステムは拡大していっています。 例:Notion、Figma、Linear、GitHub 特にAtlassian Remote MCP Server betaはサービスが公式に提供するMCPサーバーの中で、最も先進的なものの一つです
本記事では「JWTベースの認証・認可」という表現を使用しています。 認証（Authentication）：ユーザーの本人確認（ログイン時のID/パスワード検証） 認可（Authorization）：リソースへのアクセス権限の確認（JWTによる権限検証） JWTは主に認可の仕組みとして機能しますが、認証から認可までの一連のシステムを指して「JWTベースの認証・認可」と表現しています。 1.1 JWTの登場背景と従来の認証方式の課題 従来のWebアプリケーションでは、「セッション・Cookie認証」が認証方式の主流でした。これは、サーバー側でユーザーの認証状態をセッションとして管理する方式です。 セッション・Cookie認証の基本的な流れ ユーザーがログインすると、サーバーはセッションIDを発行します。 サーバーは、そのセッションIDとユーザー情報を紐付けて自身のストレージ（セッションストレー
はじめに Web アプリケーションサーバーを実装するうえで、認可処理については頻繁に議論されているかつ実装の難しさを指摘されることが多い分野です。認可制御を適切に行わないと、権限のないユーザーがリソースにアクセスできる脆弱性が生じる可能性があり、ソフトウェア開発をする上で重要な実装です。本稿では、Rust と Clean Architecture(DDD) を用いた Web アプリケーションサーバーにおいて、安全な認可の仕組みをどのように実装できるかを考察します。これは、実際にRust と Clean Architecture を用いて RESTAPI サーバーを実装するうえで直面した課題を基に検討したものです。 ※文章構成の都合で一部時系列を入れ替えていますが、ご容赦ください。 前提本稿では、Web アプリケーションフレームワークとして Axum を使用したソースコードを掲示して
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
