Skip to content

Latest commit

 

History

History
199 lines (143 loc) · 9.32 KB

README.ja.md

File metadata and controls

199 lines (143 loc) · 9.32 KB
Raw

認可サーバー実装 (C#)

概要

OAuth 2.0 と OpenID Connect をサポートする認可サーバーの C# による実装です。

この実装は、ASP.NET Core API と、NuGet パッケージ Authlete.Authlete として提供される authlete-csharp ライブラリを用いて書かれています。

この実装は「DB レス」です。 これの意味するところは、認可データ (アクセストークン等) や認可サーバー自体の設定、クライアントアプリケーション群の設定を保持するためのデータベースを管理する必要がないということです。 これは、Authlete をバックエンドサービスとして利用することにより実現しています。

Authlete のアーキテクチャーの詳細については、 New Architecture of OAuth 2.0 and OpenID Connect Implementation をお読みください。真のエンジニアであれば、このアーキテクチャーを気に入ってくれるはずです ;-) なお、日本語版は「OAuth 2.0 / OIDC 実装の新アーキテクチャー」です。

The primary advantage of this architecture is in that the backend service can focus on implementing OAuth 2.0 and OpenID Connect without caring about other components such as identity management, user authentication, login session management, API management and fraud detection. And, consequently, it leads to another major advantage which enables the backend service (implementation of OAuth 2.0 and OpenID Connect) to be combined with any solution of other components and thus gives flexibility to frontend server implementations.

このアーキテクチャーの一番の利点は、アイデンティティー管理やユーザー認証、 ログインセッション管理、API 管理、不正検出などの機能について気にすることなく、 バックエンドサービスが OAuth 2.0 と OpenID Connect の実装に集中できることにあります。 この帰結として、バックエンドサービス (OAuth 2.0 と OpenID Connect の実装) をどのような技術部品とも組み合わせることが可能というもう一つの大きな利点が得られ、 フロントエンドサーバーの実装に柔軟性がもたらされます。

Please read New Architecture of OAuth 2.0 and OpenID Connect Implementation for details about the architecture of Authlete. True engineers will love the architecture ;-)

The primary advantage of this architecture is in that the backend service can focus on implementing OAuth 2.0 and OpenID Connect without caring about other components such as identity management, user authentication, login session management, API management and fraud detection. And, consequently, it leads to another major advantage which enables the backend service (implementation of OAuth 2.0 and OpenID Connect) to be combined with any solution of other components and thus gives flexibility to frontend server implementations.

ライセンス

Apache License, Version 2.0

ソースコード

https://github.com/authlete/csharp-oauth-server

実行方法

  1. この認可サーバーの実装をダウンロードします。

     $ git clone https://github.com/authlete/csharp-oauth-server.git
 $ cd csharp-oauth-server/AuthorizationServer

  2. 設定ファイルを編集して API クレデンシャルズをセットします。

     $ vi authlete.properties

  3. Start the authorization server on http://localhost:5000.

     $ dotnet run

設定ファイル

csharp-oauth-server は authlete.properties を設定ファイルとして参照します。 他のファイルを使用したい場合は、次のようにそのファイルの名前を環境変数 AUTHLETE_CONFIGURATION_FILE で指定してください。

$ export AUTHLETE_CONFIGURATION_FILE=local.authlete.properties

エンドポイント

この実装は、下表に示すエンドポイントを公開します。

エンドポイント パス
認可エンドポイント /api/authorization
トークンエンドポイント /api/token
JWK Set ドキュメントエンドポイント /api/jwks
設定エンドポイント /.well-known/openid-configuration
取り消しエンドポイント /api/revocation
イントロスペクションエンドポイント /api/introspection

認可エンドポイントとトークンエンドポイントは、RFC 6749、OpenID Connect Core 1.0、 OAuth 2.0 Multiple Response Type Encoding Practices、RFC 7636 (PKCE)、 その他の仕様で説明されているパラメーター群を受け付けます。

JWK Set ドキュメントエンドポイントは、クライアントアプリケーションが (1) この OpenID プロバイダーによる署名を検証できるようにするため、また (2) この OpenID へのリクエストを暗号化できるようにするため、JSON Web Key Set ドキュメント (JWK Set) を公開します。

設定エンドポイントは、この OpenID プロバイダーの設定情報を OpenID Connect Discovery 1.0 で定義されている JSON フォーマットで公開します。

取り消しエンドポイントはアクセストークンやリフレッシュトークンを取り消すための Web API です。 その動作は RFC 7009 で定義されています。

イントロスペクションエンドポイントはアクセストークンやリフレッシュトークンの情報を取得するための Web API です。 その動作は RFC 7662 で定義されています。

認可リクエストの例

次の例は Implicit フローを用いて認可エンドポイントからアクセストークンを取得する例です。 {クライアントID} となっているところは、あなたのクライアントアプリケーションの実際のクライアント ID で置き換えてください。 クライアントアプリケーションについては、Getting Started および開発者コンソールのドキュメントを参照してください。

http://localhost:5000/api/authorization?client_id={クライアントID}&response_type=token

上記のリクエストにより、認可ページが表示されます。 認可ページでは、ログイン情報の入力と、"Authorize" ボタン (認可ボタン) もしくは "Deny" ボタン (拒否ボタン) の押下が求められます。 ログイン情報として、下記のいずれかを使用してください。

ログイン ID パスワード
john john
jane jane

もちろんこれらのログイン情報はダミーデータですので、ユーザーデータベースの実装をあなたの実装で置き換える必要があります。

カスタマイズ

この実装をカスタマイズする方法については CUSTOMIZATION.ja.md に記述されています。 Authlete はユーザーアカウントを管理しないので、基本的には「ユーザー認証」に関わる部分についてプログラミングが必要となります。 これは設計によるものです。 ユーザー認証の仕組みを実装済みの既存の Web サービスにもスムーズに OAuth 2.0 と OpenID Connect の機能を組み込めるようにするため、Authlete のアーキテクチャーは認証と認可を慎重に分離しています。

その他の情報

コンタクト

目的 メールアドレス
一般 [email protected]
営業 [email protected]
広報 [email protected]
技術 [email protected]