インターン生が挑戦した認証方式の移行──メルペイ加盟店管理画面へのOAuth 2.0導入

インターン生が挑んだ認証方式のマイグレーション──メルペイ加盟店管理画面への OAuth 2.0 導入 こんにちは。メルペイ Partner Platform チームでバックエンドエンジニアのインターンをしている@taki と申します。この記事は、Merpay & Mercoin Advent Calendar 2025 の 22 日目の記事です。 Partner Platform チームではメルペイの加盟店向けの管理画面を開発しています。本記事では、インターン期間中に取り組んだタスクの一つである、管理画面の認証方式をマイグレーションした経験について紹介します。 メルペイでは、加盟店向けに管理画面を提供しています。この画面では、店舗でのメルペイの取引履歴の確認など、さまざまな機能を利用できます。 ![](https://storage.googleapis.com/prd-engineering-asset/2025/12/bb6a683a-partner_dashboard.png) 現在の管理画面では、以下のようなフローの認証方式を採用しています。 ログイン：お客さまが送信したメールアドレス・パスワードを用いて、加盟店管理画面側で認証を行います。 リソース取得：認証が成功するとアクセストークンが発行され、そのトークンを用いて依存先の各マイクロサービスにリクエストを行います。 ![](https://storage.googleapis.com/prd-engineering-asset/2025/12/36e27015-screenshot-2025-12-19-at-13.50.28.png) このロジックはシンプルですが、大きな課題があります。それは、他サービス（例えばメルカリ Shops やメルカリ Ads など）の加盟店管理画面とは独立した認証体系になってしまっているということです。 そのため、例えばメルペイとメルカリ Shops の両方を利用している加盟店のスタッフは、それぞれのサービスの管理画面で異なるアカウントを発行する必要があります。 そこで今回、この課題の解決に向けて、認証方式のマイグレーションを行いました。新しい方式の基本的なフローは以下の通りです。 ログイン：お客さまはまず認可サーバにメールアドレス・パスワードを送信し、認証を行います。ここで使用する認可サーバは、メルカリの IDP チームが提供しているものです。 トークンを要求：加盟店管理画面側から、認可用のトークンを認可サーバにリクエストします。 トークンを発行：認可サーバがトークンを発行します。 リソース取得：発行されたトークンを用いて、加盟店管理画面から依存先のマイクロサービスにアクセスします。 ![](https://storage.googleapis.com/prd-engineering-asset/2025/12/88ba5085-screenshot-2025-12-19-at-13.51.24.png) この方式では、認証・認可のフローが各サービスから分離され、共通の認可サーバに集約されます（下図参照）。これにより、将来的にはお客さまがさまざまなサービスの加盟店管理画面に、共通のアカウントでログインできるようになります。（メルカリ Shops に関しては OAuth へのマイグレーションが別途で必要になります。） ![](https://storage.googleapis.com/prd-engineering-asset/2025/12/40420e23--2025-12-19-14.39.30.png) この仕組みは、技術的には OAuth 2.0 および OIDC（OpenID Connect）というプロトコルを使用しています。以下では、OAuth 2.0 について簡単に説明します。 OAuth 2.0 は、サードパーティアプリケーションがお客さまのリソースに安全にアクセスするための認可（Authorization）プロトコルです。 OAuth 2.0 では、以下の 4 つの登場人物が出てきます。 リソースオーナー（Resource Owner）: リソースの所有者であるお客さま。今回のケースでは加盟店のスタッフです。 クライアント（Client）: リソースにアクセスしたいアプリケーション。今回のケースでは加盟店管理画面（の BFF：Backend For Frontend）です。 認可サーバ（Authorization Server）: お客さまを認証し、アクセストークンを発行するサーバ。今回のケースでは IDP チームが提供する認可サーバです。 リソースサーバ（Resource Server）: 保護されたリソースを保持するサーバ。今回のケースでは加盟店管理画面から呼び出される各種マイクロサービスです。 OAuth 2.0 にはいくつかのフロー（グラントタイプ）があります。その中で、Web アプリケーションで最も一般的なのは Authorization Code Flow というものです。今回実装したフローも、このフローを採用しています。 基本的な流れは以下の通りです。 認可リクエスト: お客さまがログインを試みると、クライアントはお客さまを認可サーバにリダイレクトし、認可を要求します。 ログイン: 認可サーバでお客さまがログインします。 認可コードの発行: 認可サーバは認可コードを発行し、クライアントにリダイレクトします。 トークンを要求: クライアントは認可コードを認可サーバに送信し、アクセストークンを要求します。 トークンを発行: 認可サーバは、正当なクライアントからのリクエストかどうかを検証した上で、アクセストークンを発行します。 リソース取得: クライアントはアクセストークンを使用して、リソースサーバの API にアクセスします。 先ほどの図ではこのフローを一部省略して描いていましたが、OAuth 2.0 のフローを踏まえてちゃんと描くと以下のような形になります。 ![](https://storage.googleapis.com/prd-engineering-asset/2025/12/0a14ec2e-screenshot-2025-12-19-at-13.51.06.png) 実装に入る前に、まず要件を整理する必要がありました。具体的には、既存のロジックのどの部分をどの順序で変更するべきか調査し、チケットを切るところから始めました。 この際、参考にしたのがスキマバイト「メルカリ ハロ」の加盟店管理画面です。メルカリ ハロは最も早く OAuth による認可を導入していたサービスでした。実際にメルカリ ハロの管理画面を触ってみた上で、メルカリ ハロへの OAuth 導入時のドキュメント、および実装を照らし合わせながら理解することで、実装の進め方の解像度を大きく高めることができました。 残念ながらメルカリ ハロは2025年12月をもってサービスが終了しましたが、メルカリ ハロで行われたさまざまな技術的挑戦で得られた知見は、こうして他のプロダクトに生かし続けられるということを実感しました。 実装の方針を立てた後、実際の開発に取り掛かりました。認可サーバ側の認証・認可のロジックはIDPチーム側で既に実装されていたため、今回の開発では加盟店管理画面のBFFにおける処理の実装がメインとなりました。具体的には、上の図の③のリダイレクトを受け付ける部分や、④⑤のトークン発行の部分などです。 OAuthのフローでは、加盟店管理画面のBFFは、ブラウザとの直接通信を多用します。例えば、ブラウザにリダイレクトを行わせたり、⑤で受け取ったアクセストークンをブラウザのCookieにセットしたりする必要があります。 そのため、これらの処理はサーバ間通信の仕組みであるgRPCサーバではなく、HTTPサーバで行うのが適切です。しかし、元々のBFFにはgRPCサーバしか存在しなかったため、新たにHTTPサーバを構築する必要がありました（下図の赤色部分）。 実装では、gRPCサーバと同一プロセス内の別ポートでHTTPサーバを立ち上げるようにしました。さらに、Kubernetesのポート公開の設定やGatewayのプロキシ設定を変更することで、無事にHTTPサーバを疎通させることができました。 続いて、新しく立てたHTTPサーバに、③や④⑤などのフローを行うためのエンドポイントを実装し、テスト環境でOAuthによる認可を動かすところまでを実現できました。 メルペイでの約3ヶ月間のインターンを通して、強く感じたことは、メルペイのエンジニアは一般的なエンジニアの担当領域にとどまらず、事業側へのインパクトを解像度高く把握してプロダクトに関わっているということです。 実際、自分の周りのメンターの方々は、単に与えられた仕様を実装するのではなく、「自分の開発しているものが、お客さまにどのような価値をもたらし、その価値が事業の成長や収益にどうつながるのか」まで踏み込んで議論しながらプロダクトに向き合っていると感じました。 そういった視点を前提に、必要に応じて周囲のチームと連携しながら、仕様の見直しなども含めて主体的に開発を進めていく──このスタイルがマネージャー層だけでなく、一人ひとりのエンジニアにまで根付いていることは、自分にとって大きな驚きであり、とても魅力的な環境だと感じました。 そして、メルペイのエンジニアがこのような動きをできる理由の一つとして、メルカリ・メルペイにはVibe CodingやAgentic Codingが深く浸透しているということがあると感じました。「Coding Agentの登場によって、エンジニアの役割はアーキテクトへと変化していく」とはよく言われていることですが、メルカリではこの変化がすでにかなり進んでいると実感すると共に、自分もこのようなエンジニアを目指したいと感じる経験となりました。 この記事では、メルペイのインターンで取り組んだ認証方式のマイグレーション、そしてインターンを通して感じたことをまとめました。 インターン期間中は、この記事で述べた内容に限らず、技術的な面でも、それ以外の面でも、さまざまな学びを得ることができました。 残りのインターン期間では、OAuth の導入に関する QA を実施し、本番環境へのリリースまで完了させたいと考えています。 明日の記事は@kubomi さんです。引き続きお楽しみください。 ![](/img/In-Blue-128@2x.png) ![](https://b.st-hatena.com/images/v4/public/entry-button/button-only@2x.png) Advent Calendar Related article 2026/01/06 ![](https://storage.googleapis.com/prd-engineering-asset/2025/12/5bc093c7-cleanshot-2025-10-30-at-12.11.18-1.png) TTL を利用した TiDB の効率的なインスタンス活用 2025/12/21 ![](https://storage.googleapis.com/prd-engineering-asset/2025/12/0d77977d-adventcalendar2025_mercari.png) Non-AI tasks in the AI task force：AI ツール開発の現場でこそ必要な「AI 以外の」技術選定 Author: akkie30 2025/12/20 ![](https://storage.googleapis.com/prd-engineering-asset/2025/11/cf9f9e27-adventcalendar2025_merpaymercoin.png) LLM を用いたおしゃべり機能「しゃべるおさいふ」のバックエンド設計 Author: kobaryo

インターン生が挑戦した認証方式の移行──メルペイ加盟店管理画面へのOAuth 2.0導入

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト