DocsPricingBlog
Contact Us
Log inSign up for FREE
Back to Tech Articles

RustバックエンドにおけるOAuth 2.0認可コードフローを使ったセキュアな構築

Sep 04, 2025
# Misc

Grace Collins

Solutions Engineer · Leapcell

This post is also available in English, 한국어, and Deutsch
Cover of "RustバックエンドにおけるOAuth 2.0認可コードフローを使ったセキュアな構築"

はじめに：RustアプリケーションをOAuth 2.0で保護する

今日の相互接続されたデジタルランドスケープにおいて、ユーザー認証と認可は、あらゆるWebアプリケーションにとって最優先事項です。開発者として、私たちは安全でスケーラブル、かつユーザーフレンドリーなシステムを構築するよう努めています。機密性の高い認証情報を直接処理することなくユーザーアクセスを管理するという点では、OAuth 2.0は広く採用され、堅牢なフレームワークとして際立っています。特に、認可コードフローは、アクセストークンの露出を最小限に抑えるため、Webアプリケーションで推奨される最も安全な方法です。

パフォーマンス、メモリ安全性、並行性に重点を置いたRustは、バックエンドサービスを構築するための魅力的な選択肢となっています。RustバックエンドにOAuth 2.0を統合することで、開発者はRustの強みを活かしつつ、保護されたリソースへの安全なアクセスを提供できます。この記事では、RustバックエンドでOAuth 2.0認可コードフローを実装するプロセスをガイドし、その根本原理を説明し、実践的なコード例を示します。

OAuth 2.0認可コードフローのコアコンセプト

実装の詳細に入る前に、OAuth 2.0認可コードフローに関わる主要な役割とステップを明確に理解しましょう。

  • リソースオーナー (Resource Owner): 保護されたリソース（例：写真、プロファイルデータなど）を所有し、アクセスを許可するエンドユーザーです。
  • クライアント (Client) (あなたのRustアプリケーション): リソースオーナーの保護されたリソースへのアクセスを要求するアプリケーションです。認可サーバーに登録されています。
  • 認可サーバー (Authorization Server): リソースオーナーを認証し、リソースオーナーの同意を得た後にクライアントにアクセストークンを発行します。
  • リソースサーバー (Resource Server): 保護されたリソースをホストし、クライアントへのアクセスを許可するためにアクセストークンを受け入れます。多くの場合、認可サーバーとリソースサーバーは同じエンティティであるか、密接に統合されています。

認可コードフローは、以下の高レベルのステップで進行します。

  1. 認可リクエスト (Authorization Request): クライアント（フロントエンドによって開始されるあなたのRustバックエンド）は、リソースオーナーのブラウザを認可サーバーにリダイレクトします。このリクエストには、クライアントID、要求されたスコープ、およびredirect_uriが含まれます。
  2. ユーザー認証と同意 (User Authentication and Consent): 認可サーバーは、リソースオーナーを認証し（まだログインしていない場合）、要求されたスコープに対するクライアントへのアクセスを許可または拒否するように促します。
  3. 認可付与（認可コード）(Authorization Grant (Authorization Code)): リソースオーナーがアクセスを許可した場合、認可サーバーはブラウザをクライアントのredirect_uriにリダイレクトし、authorization_codeを含めます。
  4. トークンリクエスト (Token Request): クライアント（あなたのRustバックエンド）は、認可サーバーのトークンエンドポイントに直接、サーバー間リクエストを送信します。このリクエストには、authorization_code、クライアントID、クライアントシークレット、およびredirect_uriが含まれます。
  5. トークンレスポンス (Token Response): 認可サーバーはリクエストを検証し、成功した場合は、access_token、refresh_token（オプション）、およびexpires_in（トークンの有効期間）を返します。
  6. リソースアクセス (Resource Access): クライアントは、access_tokenを使用して、保護されたリソースへのリクエストをリソースサーバーに送信します。

RustでのOAuth 2.0認可コードフローの実装

ここでは、Rustを使用して簡略化された実装を検討し、バックエンドが認可コードを処理し、トークンと交換する役割に焦点を当てます。Webフレームワークとしてactix-web、HTTPリクエストにreqwestを使用します。フロントエンドが初期リダイレクトを処理し、最終的にブラウザ経由で認可コードを受け取ることを想定しています。

プロジェクトのセットアップ

まず、新しいRustプロジェクトを作成し、必要な依存関係を追加します。

cargo new oauth2_backend --bin
cd oauth2_backend

次に、これらをCargo.tomlに追加します。

[dependencies]
actix-web = "4"
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
reqwest = { version = "0.11", features = ["json", "blocking"] } # 単純化のためにblockingを使用。実際のアプリではasyncが推奨される
url = "2.2"
dotenv = "0.15"
# 環境変数を簡単に管理するため

OAuth 2.0の認証情報やその他の設定のために、.envファイルを作成します。

CLIENT_ID="your_client_id"
CLIENT_SECRET="your_client_secret"
REDIRECT_URI="http://localhost:8080/callback"
AUTH_SERVER_AUTH_URL="https://example.com/oauth/authorize" # 認可サーバーのURLに置き換えてください
AUTH_SERVER_TOKEN_URL="https://example.com/oauth/token"   # 認可サーバーのURLに置き換えてください

コアロジック：コールバックとトークン交換の処理

私たちのRustバックエンドは、主にredirect_uriエンドポイントを処理します。ここで認可サーバーが認可コードを送信します。

// src/main.rs
use actix_web::{web, App, HttpResponse, HttpServer, Responder, http::header};
use serde::{Deserialize, Serialize};
use url::Url;
use dotenv::dotenv;
use std::env;

// OAuth 2.0クライアントの詳細を保持する設定構造体
struct AppConfig {
    client_id: String,
    client_secret: String,
    redirect_uri: String,
    auth_server_auth_url: String,
    auth_server_token_url: String,
}

// 認可サーバーからの受信クエリパラメータを表す構造体
#[derive(Deserialize, Debug)]
struct OAuthCallbackQuery {
    code: String,
    state: Option<String>,
}

// 認可サーバーからのトークンリクエストボディを表す構造体
#[derive(Serialize, Debug)]
struct TokenRequest {
    grant_type: String,
    client_id: String,
    client_secret: String,
    redirect_uri: String,
    code: String,
}

// 認可サーバーからのトークンレスポンスを表す構造体
#[derive(Deserialize, Debug)]
struct TokenResponse {
    access_token: String,
    token_type: String,
    expires_in: u32,
    refresh_token: Option<String>,
    scope: Option<String>,
}

async fn index() -> impl Responder {
    // 実際のアプリケーションでは、通常、OAuthフローを開始するためのフロントエンドリダイレクトになります。
    // デモンストレーションのため、リンクを表示するだけにします。
    HttpResponse::Ok().body("Welcome! <a href=\"/login\">Login with OAuth</a>")
}

async fn login(data: web::Data<AppConfig>) -> impl Responder {
    let mut auth_url = Url::parse(&data.auth_server_auth_url).unwrap();
    auth_url.query_pairs_mut()
        .append_pair("client_id", &data.client_id)
        .append_pair("redirect_uri", &data.redirect_uri)
        .append_pair("response_type", "code")
        .append_pair("scope", "openid profile email") // 例のスコープ
        .append_pair("state", "random_string_for_csrf_protection"); // CSRF保護のための必須項目

    HttpResponse::Found()
        .insert_header((header::LOCATION, auth_url.to_string()))
        .finish()
}


async fn oauth_callback(
    query: web::Query<OAuthCallbackQuery>,
    data: web::Data<AppConfig>,
) -> impl Responder {
    println!("Received OAuth callback with code: {:?}", query.code);
    // 実際のアプリでは、ここでCSRF攻撃を防ぐために 'state' パラメータを検証します。

    let token_request = TokenRequest {
        grant_type: "authorization_code".to_string(),
        client_id: data.client_id.clone(),
        client_secret: data.client_secret.clone(),
        redirect_uri: data.redirect_uri.clone(),
        code: query.code.clone(),
    };

    println!("Exchanging authorization code for tokens...");
    let client = reqwest::blocking::Client::new();
    match client
        .post(&data.auth_server_token_url)
        .header(header::ACCEPT, "application/json")
        .form(&token_request) // x-www-form-urlencoded のために .form を使用
        .send()
    {
        Ok(response) => {
            if response.status().is_success() {
                match response.json::<TokenResponse>() {
                    Ok(token_response) => {
                        println!("Successfully obtained tokens: {:?}", token_response.access_token);
                        // トークンを安全に保存する（例：セッション、データベース）
                        // 保護されたリソースまたはダッシュボードにリダイレクト
                        HttpResponse::Ok().body(format!(
                            "Login successful! Access Token: {}",
                            token_response.access_token
                        ))
                    }
                    Err(e) => {
                        eprintln!("Failed to parse token response: {:?}", e);
                        HttpResponse::InternalServerError().body(format!("Failed to parse token response: {}", e))
                    }
                }
            } else {
                let status = response.status();
                let text = response.text().unwrap_or_else(|_| "N/A".to_string());
                eprintln!("Token exchange failed with status: {} and body: {}", status, text);
                HttpResponse::InternalServerError().body(format!(
                    "Token exchange failed: {} - {}", status, text
                ))
            }
        }
        Err(e) => {
            eprintln!("HTTP request for token exchange failed: {:?}", e);
            HttpResponse::InternalServerError().body(format!("HTTP request for token exchange failed: {}", e))
        }
    }
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    dotenv().ok(); // .env ファイルから環境変数をロード

    let config = AppConfig {
        client_id: env::var("CLIENT_ID").expect("CLIENT_ID not set"),
        client_secret: env::var("CLIENT_SECRET").expect("CLIENT_SECRET not set"),
        redirect_uri: env::var("REDIRECT_URI").expect("REDIRECT_URI not set"),
        auth_server_auth_url: env::var("AUTH_SERVER_AUTH_URL").expect("AUTH_SERVER_AUTH_URL not set"),
        auth_server_token_url: env::var("AUTH_SERVER_TOKEN_URL").expect("AUTH_SERVER_TOKEN_URL not set"),
    };

    println!("Server running on http://127.0.0.1:8080");
    HttpServer::new(move || {
        App::new()
            .app_data(web::Data::new(config.clone())) // アプリ設定を共有
            .route("/", web::get().to(index))
            .route("/login", web::get().to(login))
            .route("/callback", web::get().to(oauth_callback))
    })
    .bind(("127.0.0.1", 8080))?
    .run()
    .await
}

コードの説明

  1. AppConfig: 環境変数からロードされたOAuthクライアント認証情報を保持する構造体です。
  2. index および login ハンドラ: indexルートはプレースホルダーです。loginルートは、バックエンド（または通常はフロントエンド）が認可URLをどのように構築し、ユーザーのブラウザを認可サーバーにリダイレクトするかを示しています。
  3. oauth_callback ハンドラ:
    • これは、私たちのバックエンドOAuth実装の中核です。認可サーバーが認可コードを送信するredirect_uriです。
    • web::Queryを使用して、認可サーバーからクエリパラメータとして送信された認可codeを逆シリアライズします。
    • 認可コードをアクセストークンと交換するために必要なすべてのパラメータを含むTokenRequest構造体が作成されます。client_secretは安全なバックエンドから直接送信され、クライアントサイドからは絶対に送信されないことに注意してください。
    • reqwest::blocking::Client（この例では簡略化のため）を使用して、認可サーバーのトークンエンドポイントへのPOSTリクエストが送信されます。
    • TokenResponseが逆シリアライズされます。成功した場合、access_tokenと、場合によってはrefresh_tokenを取得しました。
    • 次に行うべき重要なこと（この基本的な例には含まれていません）：
      • Stateパラメータの検証: CSRF攻撃を防ぐために、必ずstateパラメータを検証してください。認可サーバーにリダイレクトする前に、ランダムなstateをサーバーで生成し、保存（例：セッションに）します。コールバックが受信されたら、受信したstateと保存されたstateを比較します。
      • トークンの保存: access_tokenを安全に保存します（例：暗号化されたセッションCookie、またはユーザーに関連付けられたデータベース）。
      • refresh_tokenの使用: refresh_tokenが提供されている場合は、安全に保存します。現在のaccess_tokenが期限切れになったときに、ユーザーが再認証することなく新しいaccess_tokenを取得するために使用します。
      • ユーザー情報の取得: 多くの場合、access_tokenを取得した後、認可サーバーのユーザー情報エンドポイント（または別の保護されたリソース）にリクエストを送信して、基本的なユーザー詳細（例：openid profileスコープ）を取得します。
  4. main 関数:
    • dotenvを使用して環境変数をロードします。
    • AppConfigを初期化します。
    • actix-webルートを設定し、web::Dataを使用してAppConfigをハンドラ間で共有します。

アプリケーションシナリオ

この実装は、いくつかの一般的なパターン（パターン）の基盤を提供します。

  • シングルサインオン (SSO): Google、GitHub、OktaなどのIDプロバイダーと統合して、ユーザーが既存のアカウントを使用してログインできるようにします。
  • サードパーティ統合: ユーザーの同意を得て、あなたのアプリケーションが他のサービス（Googleカレンダーからカレンダーを取得するなど、またはソーシャルメディアプラットフォームからの投稿など）のユーザーデータにアクセスできるようにします。
  • API認証: アクセストークンをクライアントアプリケーションに発行することにより、あなた自身のAPIを保護し、承認されたクライアントのみが保護されたバックエンドリソースにアクセスできるようにします。

結論：Rustバックエンドのための堅牢な認証

RustバックエンドにOAuth 2.0認可コードフローを実装することは、ユーザー認証と認可を管理するための、安全で柔軟で業界標準の方法を提供します。認可コードをアクセストークンと安全に交換することにより、機密情報を保護し、あなたのアプリケーションがユーザーの代わりに保護されたリソースに安全にアクセスできるようにすることを保証します。Rustの本来の安全性機能と組み合わせたこの堅牢なアプローチは、安全で高性能なWebサービスを構築するための強力な基盤を築きます。

Share this article

HackerNews

More Posts from Leapcell

Popular Posts