インターン生が挑戦した認証方式の移行──メルペイ加盟店管理画面へのOAuth 2.0導入
メルペイのインターン生が、加盟店管理画面における認証方式を従来の独自ロジックから OAuth 2.0/OIDC プロトコルへマイグレーションし、複数サービス間での共通アカウント連携の実現に向けた取り組みを報告している。
キーポイント
認証アーキテクチャの集約化
各サービスごとに独立していた認証ロジックをメルカリ IDP チームが提供する認可サーバへ集約し、加盟店管理画面間のアカウント連携を実現した。
OAuth 2.0 (Authorization Code Flow) の採用
Web アプリケーションの標準である OAuth 2.0 の Authorization Code Flow を実装し、リソースオーナー、クライアント、認可サーバ、リソースサーバという役割を明確に定義した。
先行事例からの学習と実装
メルカリハロの導入実績やドキュメントを参照し、既存システムのどの部分を順序立てて変更するかを計画して実装を進めた。
OAuthフロー対応のためのHTTPサーバ追加
ブラウザとの直接通信（リダイレクトやCookie設定）が必要なため、既存のgRPCサーバとは別に同一プロセス内でHTTPサーバを構築し、KubernetesやGatewayの設定変更により疎通を実現した。
事業インパクトを意識した開発文化
メルペイのエンジニアは単なる実装にとどまらず、自らの開発が顧客価値や事業成長にどう貢献するかを深く議論し、主体性を持って仕様見直しも行う文化が根付いている。
AI活用によるエンジニア役割の変化
Vibe CodingやAgentic Codingの浸透により、コーディングエージェントを活用したアーキテクトとしての役割変化が進んでおり、インターン生もその環境に強い魅力を感じている。
影響分析・編集コメントを表示
影響分析
この記事は、大規模プラットフォームにおけるセキュリティ基盤の標準化と、若手エンジニアが実務レベルのシステムアーキテクチャ変更にどのように取り組むかを示す貴重なケーススタディです。OAuth 2.0 の導入により、ユーザーの利便性向上だけでなく、将来的な新サービス追加時の認証コスト削減という長期的な技術的メリットをもたらします。
編集コメント
技術的な詳細な解説だけでなく、インターン生としての学習プロセスや先行事例の活用方法に言及しており、エンジニアリングカルチャーの継承という観点でも示唆に富んでいます。
インターン生が挑んだ認証方式のマイグレーション──メルペイ加盟店管理画面への OAuth 2.0 導入
こんにちは。メルペイ Partner Platform チームでバックエンドエンジニアのインターンをしている@taki と申します。この記事は、Merpay & Mercoin Advent Calendar 2025 の 22 日目の記事です。
Partner Platform チームではメルペイの加盟店向けの管理画面を開発しています。本記事では、インターン期間中に取り組んだタスクの一つである、管理画面の認証方式をマイグレーションした経験について紹介します。
メルペイでは、加盟店向けに管理画面を提供しています。この画面では、店舗でのメルペイの取引履歴の確認など、さまざまな機能を利用できます。
現在の管理画面では、以下のようなフローの認証方式を採用しています。
ログイン：お客さまが送信したメールアドレス・パスワードを用いて、加盟店管理画面側で認証を行います。
リソース取得：認証が成功するとアクセストークンが発行され、そのトークンを用いて依存先の各マイクロサービスにリクエストを行います。
このロジックはシンプルですが、大きな課題があります。それは、他サービス（例えばメルカリ Shops やメルカリ Ads など）の加盟店管理画面とは独立した認証体系になってしまっているということです。
そのため、例えばメルペイとメルカリ Shops の両方を利用している加盟店のスタッフは、それぞれのサービスの管理画面で異なるアカウントを発行する必要があります。
そこで今回、この課題の解決に向けて、認証方式のマイグレーションを行いました。新しい方式の基本的なフローは以下の通りです。
ログイン：お客さまはまず認可サーバにメールアドレス・パスワードを送信し、認証を行います。ここで使用する認可サーバは、メルカリの IDP チームが提供しているものです。
トークンを要求：加盟店管理画面側から、認可用のトークンを認可サーバにリクエストします。
トークンを発行：認可サーバがトークンを発行します。
リソース取得：発行されたトークンを用いて、加盟店管理画面から依存先のマイクロサービスにアクセスします。
この方式では、認証・認可のフローが各サービスから分離され、共通の認可サーバに集約されます（下図参照）。これにより、将来的にはお客さまがさまざまなサービスの加盟店管理画面に、共通のアカウントでログインできるようになります。（メルカリ Shops に関しては OAuth へのマイグレーションが別途で必要になります。）
この仕組みは、技術的には 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 のフローを踏まえてちゃんと描くと以下のような形になります。 
実装に入る前に、まず要件を整理する必要がありました。具体的には、既存のロジックのどの部分をどの順序で変更するべきか調査し、チケットを切るところから始めました。
この際、参考にしたのがスキマバイト「メルカリ ハロ」の加盟店管理画面です。メルカリ ハロは最も早く 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 さんです。引き続きお楽しみください。
Advent Calendar
Related article
2026/01/06 
TTL を利用した TiDB の効率的なインスタンス活用
2025/12/21 
Non-AI tasks in the AI task force：AI ツール開発の現場でこそ必要な「AI 以外の」技術選定
Author: akkie30
2025/12/20 
LLM を用いたおしゃべり機能「しゃべるおさいふ」のバックエンド設計
Author: kobaryo
原文を表示
インターン生が挑んだ認証方式のマイグレーション──メルペイ加盟店管理画面へのOAuth 2.0導入
こんにちは。メルペイPartner Platformチームでバックエンドエンジニアのインターンをしている@takiと申します。 この記事は、Merpay & Mercoin Advent Calendar 2025 の22日目の記事です。
Partner Platformチームではメルペイの加盟店向けの管理画面を開発しています。本記事では、インターン期間中に取り組んだタスクの一つである、管理画面の認証方式をマイグレーションした経験について紹介します。
メルペイでは、加盟店向けに管理画面を提供しています。この画面では、店舗でのメルペイの取引履歴の確認など、さまざまな機能を利用できます。
現在の管理画面では、以下のようなフローの認証方式を採用しています。
ログイン: お客さまが送信したメールアドレス・パスワードを用いて、加盟店管理画面側で認証を行います。
リソース取得: 認証が成功するとアクセストークンが発行され、そのトークンを用いて依存先の各マイクロサービスにリクエストを行います。
このロジックはシンプルですが、大きな課題があります。それは、他サービス（例えばメルカリShopsやメルカリAdsなど）の加盟店管理画面とは独立した認証体系になってしまっているということです。
そのため、例えばメルペイとメルカリShopsの両方を利用している加盟店のスタッフは、それぞれのサービスの管理画面で異なるアカウントを発行する必要があります。
そこで今回、この課題の解決に向けて、認証方式のマイグレーションを行いました。新しい方式の基本的なフローは以下の通りです。
ログイン: お客さまはまず認可サーバにメールアドレス・パスワードを送信し、認証を行います。ここで使用する認可サーバは、メルカリのIDPチームが提供しているものです。
トークンを要求: 加盟店管理画面側から、認可用のトークンを認可サーバにリクエストします。
トークンを発行: 認可サーバがトークンを発行します。
リソース取得: 発行されたトークンを用いて、加盟店管理画面から依存先のマイクロサービスにアクセスします。
この方式では、認証・認可のフローが各サービスから分離され、共通の認可サーバに集約されます（下図参照）。これにより、将来的にはお客さまがさまざまなサービスの加盟店管理画面に、共通のアカウントでログインできるようになります。（メルカリShopsに関してはOAuthへのマイグレーションが別途で必要になります。）
この仕組みは、技術的には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のフローを踏まえてちゃんと描くと以下のような形になります。
実装に入る前に、まず要件を整理する必要がありました。具体的には、既存のロジックのどの部分をどの順序で変更するべきか調査し、チケットを切るところから始めました。
この際、参考にしたのがスキマバイト「メルカリ ハロ」の加盟店管理画面です。メルカリ ハロは最も早く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さんです。引き続きお楽しみください。
Advent Calendar
Related article
2026/01/06 TTLを利用したTiDBの効率的なインスタンス活用
2025/12/21 Non-AI tasks in the AI task force：AIツール開発の現場でこそ必要な「AI以外の」技術選定
Author: akkie30
2025/12/20 LLMを用いたおしゃべり機能「しゃべるおさいふ」のバックエンド設計
Author: kobaryo
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み