まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:auth0

自分が作るアプリの中でユーザー認証/登録といった機能が必要な場合、自分の場合は自作することはほとんどなく、IDaaS 等と呼ばれている SaaS 系専用サービスを使って実装しています。具体的には(資料が充実しているという理由ですが) Auth0AppID を使うことが多いです。単なるユーザー認証だけでなく、(実装する場合に面倒な)オンラインサインアップやパスワード再設定、パスワード忘れ時のリセット機能などをサービスが既にセキュアな形で組み込まれていて、自分ではほぼ実装を意識することなく使えて便利※です。

※もう少しちゃんと説明すると、Auth0 の場合であれば認証自体は OAuth を使って auth0.com で行い、認証情報が正しければコールバックで受け取った情報を使ってアクセストークンを取得できる、というロジックを簡単に実装できます。


この Auth0 を使ってアプリを作った場合、ユーザー名(表示名)やそのアイコン画像は(特定のルールに基づいて)登録時に決まります。ユーザー名はともかく、特にアイコン画像は自動生成されたものではなく自分で気に入っているものを使いたいと感じることが多いと思っています。が、現状ユーザー本人が直接変更することはできません。登録時に決まったものを使い続ける、ということになるので、こだわりを持ったユーザー名やユーザーアイコンへの変更ができないことを問題と感じていました。

で、Auth0 を調べたところ「変更用の API 自体は提供されている」ことが分かりました。要はユーザーが直接変更する機能は提供されていないが、その機能を自分で自分のアプリ内に作る方法は提供されている、ということになります。これを Node.js で早速試してみたのが今回のブログエントリのテーマです。


【プロフィール画像変更 API】
例えばプロフィール画像を変更する API 自体はこのように提供されています(下図は Node.js のサンプル):
2023022001


この上図で言うところの USER_ID 部分に画像を変更したいユーザーの ID(Auth0 上での User.id)を指定し、また変更後の画像 URL を picture の値として指定した上で上述の REST API を実行すればよい、ということになります。

特に Node.js の場合は同様の処理をより簡単に実行できるような SDK も提供されており、こちらを使った場合は ManagementClient クラスの update メソッドに必要なパラメータを渡して実行するだけです。

なおどちらの例もユーザーのアイコン画像(picture)だけを変更する例として紹介されていますが、実際には picture 以外にも nickname(表示名)や firstName, lastName など他の多くの属性を変更することも可能です。 実装そのものは後者(SDK)の方が簡単なので、以下こちらを使って説明を続けます。


【client_id と client_secret の準備】
この API を実行するには Auth0 の認証アプリを作る時と同様に client_id と client_secret (と domain)情報が必要です。ただ多くの場合、取得し直しが必要になる点に注意が必要です。以下は Auth0.com にログインし、メニューから Applications - Applications を選択した後に "Create Application" を実行した時の画面です:
2023022004


Auth0 を使って自分のアプリに認証機能を付加する場合、そのアプリの種類によって "Native(スマホ向けネイティブアプリ)", "Single Page Web Application(SPA)", "Regular Web Applications(その他のいわゆる「ウェブアプリ」)" のいずれかから1つ選んで(Auth0 の)アプリケーションを登録することが多いはずです:
2023022002


ですが、今回の機能を実現するためには "M2M(Machine to Machine)Applications" の client_id と client_secret が必要になります。そのため、まだ M2M アプリを作ったことがない場合は Machine to Machine Applications を選択して、新たに1つ追加登録してください:
2023022003


次の画面で対象 API を選択しますが、M2M アプリの場合は "Auth Management API" の1つしか選択肢がないので、これを選択します:
2023022006


最後に API の許可スコープを指定します。今回はユーザー管理機能を実装するので、検索バーに "users" と入力し、そこで見つかる全てのスコープにチェックを入れて、最後に "Authorize" ボタンをクリックするとアプリケーション登録が完了します:
2023022007


こうして Auth0.com に作成(追加)した M2M アプリケーションの Client ID、Client Secret(と Domain ですが、Domain は他のアプリ登録時に取得したものと同じはずです)が必要になります。利用時にすぐ取得できるようコピー&ペースト等で準備しておいてください:
2023022005


【実装】
ここまでの準備ができたら実装してみましょう。Node.js の場合は auth0 という便利なクライアントライブラリの SDK があるので、これを使って実装します。なお最後にサンプルアプリ・ソースのリンクを載せておくので、興味ある方はそちらをダウンロード後に実際に動作確認してみてください。

まず auth0 をインスタンス化します:
//. Auth0 Management API
var ManagementClient = require( 'auth0' ).ManagementClient;
var auth0 = new ManagementClient({
  domain: 'xxxx.auth0.com',       // domain の値
  clientId: 'client_id',          // client_id の値
  clientSecret: 'client_secret',  // client_secret の値
  scope: 'create:users read:users update:users'
});


auth0 の ManagementClient を取得し、domain, client_id, client_secret の3つの値と、スコープとして 'create:users read:users update:users' を指定してインスタンス化します(今回はプロフィール画像 URL を更新するため、これら全てがスコープとして必要になります)。繰り返しになりますが、重要なのはここで指定する client_id や client_secret は通常のネイティブアプリケーション/ウェブアプリケーションのものではなく、M2M アプリケーションとして登録したアプリケーションのものを使う必要がある、という点です。

そして実際に user_id = 'abcabc' のユーザーのプロフィール画像 URL を変更する場合は、以下のような処理を行います:
var params = { user_id: 'abcabc' };  // ユーザーIDが 'abcabc' の人が対象
var metadata = { picture: 'https://manholemap.juge.me/imgs/logo.jpg' };  // プロフィール画像を指定 URL のものに変更する
auth0.users.update( params, metadata, function( err, user ){
  if( err ){
    console.log( { err } );
        :  // エラー時の処理
  }else{
    console.log( { user } );
        :  // 成功時の処理
  }
});


実行する関数は auth0.users.update() で、この実行時パラメータとして第一パラメータに対象ユーザーの情報、第二パラメータに変更内容を指定します。実行後にエラーか成功かを識別して処理を続けます。

上の例だとプロフィール画像だけを変更していますが、複数の属性を同時に変更することも可能です。例えば以下の例は対象ユーザーのプロフィール画像(picture)と表示名(nickname) を同時に変更しています:
var params = { user_id: 'abcabc' };
var metadata = { nickname: '俺', picture: 'https://manholemap.juge.me/imgs/logo.jpg' };
auth0.users.update( params, metadata, function( err, user ){
  if( err ){
    console.log( { err } );
        :
  }else{
    console.log( { user } );
        :
  }
});


参考になれば、と思って実際に動くサンプルアプリを用意しました:
https://github.com/dotnsf/auth0-userpicture


サンプルアプリを実際に動かす場合は Auth0 に(M2M ではない通常の Web)アプリケーションも登録し、その client_id, client_secret, domain を取得し、また OAuth のコールバックURL(callback_url) を実行時の環境変数に登録する必要があります。実行時の環境変数登録時は同リポジトリ内の .env ファイルにその内容を記載することでも代替可能です。



参照していただくとわかるのですが、実際にユーザーの属性を変更しようとすると対象ユーザーの ID が必要になります。ユーザー ID は OAuth でログイン後にわかるので、実際のアプリケーションでは普通の(通常のウェブの)アプリケーションと、ユーザー管理用の M2M アプリケーションの2つを登録する必要があり、それぞれの client_id と client_secret の両方を使って実装することになります。詳しくはソースコード内を参照ください。


自分は多くのウェブサービスやウェブアプリを開発/公開していますが、そのほとんどが無料です。中には「有償でもいいかな?」と思えるものもあったりしますが、無料で公開している最大の理由は「課金管理の仕組みが難しい」からというのが大きいです。

自分で作ったサービスを有料公開しようとすると、いくつかの問題点が出てきます。まずそもそも「どうやって支払ってもらうのか?」を解決する必要があります。理想的には月額制サブスクにして、クレジットカードで・・みたいな感じになりますが、クレジットカードと連動する仕組みを個人で用意するのはかなり大変です。クレジットカード情報は自サービスに記録しないとしても、サービスと連動させるための情報は記録する必要があり、場合によっては個人情報保護も考慮する必要が出てきます。 個人情報を取得しなかった場合でも自サービスのユーザーの情報は自サービス内で管理する必要があります。ログインとかオンラインサインアップとか、パスワードを忘れてしまった場合のリセットなどです。これらの仕組みを提供してユーザーを管理した上で、どのユーザーが有償サービスに移行して、どのユーザーは無料ユーザーのままで、そして有償サービスに移行したユーザーはどういうプランで・・・といった情報をすべて管理する必要があるのでした。これらを解決するための仕組みづくりがサービス本体と比べてもかなり面倒なのでした。多くの個人開発者が共通に悩む点だと思っています。

そんな中で一念発起して、この「ユーザー管理&課金管理」に挑戦してみました。今回はユーザー管理機能として Auth0 を、課金部分は LINE Pay を使ってみました。いずれも Node.js 向けの外部連携ウェブ API (SDK) が提供されていて、普段の自分が開発している環境で比較的容易に実現できるものでした。ユーザー管理機能は Auth0 である必要はありませんが、他の IDaaS を使う場合はその IDaaS 向けにログインやログアウト、オンラインサインアップ等を実装する必要があります。ユーザー毎の課金管理はこのアプリ内のデータベースで管理しますが、その際に使うユーザーの ID をどのように用意するかをあらかじめ考慮しておく点がある点に注意ください。例えば後述のサンプルでは Auth0 のユーザーIDをそのまま使っています。これを見た目でよりわかりやすくするために、ユーザーのメールアドレスを ID として利用することも可能ですが、その場合は個人情報をデータベースに記録することになる、という点に留意が必要です(それが問題ないケースであれば、メールアドレスをユーザー ID とするのがリーズナブルだと思っています。今回は個人情報取得を避ける目的でユーザーを特定しにくい ID を使っています)。

以下にサンプルアプリの使い方と、そのサンプルアプリを利用するための準備作業を記載していきます。なお実際に動かす場合(実際の支払いは発生しませんが、一連の手順を確認する場合)、本アプリでは支払いに LINE Pay を使うので、LINE のアカウントと LINE のインストールされたスマートフォンが必要になります。こちらは事前に用意してください(※後述のサンプルは実際に料金を支払うわけではないのですが、LINE Pay の仕組みを使って支払い処理を行うことにはなるので LINE のインストールされたスマホが必要です)。

【PostgreSQL データベースの準備】
本サンプルアプリケーションでは(Auth0 の)ユーザーと、そのトランザクションを PostgreSQL データベースを使って紐づけて管理します。そのため PostgreSQL データベースが必要です。

クラウド環境でも、ローカルへのインストールでも、Docker コンテナなどでも構わないので、PostgreSQL データベースを1つ用意してください。以下では
 postgres://user:pass@xx.xx.xx.xx:5432/db  
(ユーザー名=user、パスワード=pass で利用可能なデータベース db が xx.xx.xx.xx:5432 で動いている)

という URL でアクセスできる PostgreSQL データベースが存在している想定で説明を続けます。


【IDaaS (Auth0)側の準備】
本サンプルではユーザー管理機能として Auth0 を使います。そのため Auth0 のアカウントを取得した上で、アプリ連携するための準備が必要です。Auth0 のアカウントを未取得の場合はこちらからサインアップしてください(開発用の無料アカウントでかまいません):
https://auth0.com/signup

アカウント取得後にログインし、ダッシュボード画面で「アプリケーション」を1つ作成します。ログイン後のダッシュボード画面左で "Applications" - "Applications" を選び、画面右上に表示される "Create Applications" ボタンをクリックします:
2022090501


"Create application" ダイアログが表示されるので、アプリケーション名(下図では "LINE Pay with IDaaS")を適当に入力後、"Regular Web Applications" を選択してから "Create" ボタンをクリックします:
2022090502


アプリケーション作成後に "Settings" タブを選択します。そして Domain, Client ID, Client Secret とそれぞれ書かれた3つのフィールドに値が設定された値を確認します(これらの値は後で必要になります):
2022090503


そのまま下にスクロールして、"Application URLs" を探します。ここには "Application Login URLs", "Application Callback URLs", "Allowed Logout URLs", ・・といった設定項目が並んでいます。最初の "Application Login URLs" は空のままでいいのですが、次の2つにはそれぞれ以下を入力します(※1):
 ・"Application Callback URLs": "http://localhost:8080/auth0/callback"
 ・"Allowed Logout URLs": "http://localhost:8080"
2022090601


※1 これらは localhost 上で動かす場合の指定です。このアプリをインターネット上の公開サーバーで実行する場合は、そのホスト名や IP アドレスも URL 形式で指定する必要があります。複数の URL を指定する場合は半角カンマで区切って指定します。


ここまで指定できたら画面の最下部までスクロールして "Save Changes" ボタンをクリックして内容を保存します。これで Auth0 の(最低限の)準備は完了です:
2022090602



この後でサンプルアプリケーションを動かします。その際に利用するユーザーは(そのユーザーのメールアドレスを使って)オンラインサインアップすることもできるのですが、この時点で直接作成しておくこともできます。ここではユーザーの作成方法を紹介するので、この方法でアプリケーションで利用するユーザーを作るか、あるいは後ほどアプリケーション実行時にオンラインサインアップしてユーザー登録を行ってください。

Auth0 のユーザーをダッシュボードから作成する場合は、左メニューで "User Management" - "Users" を選び、画面右上の "Create User" ボタンをクリックします:
2022090603


"Create user" ダイアログが表示されるので、上からメールアドレス、パスワード、パスワード確認を入力します。また "Connection" は "Username-Password-Authentication" を選択したままにします。最後に右下の "Create" ボタンをクリックするとユーザーを直接登録することができます:
2022090604


作成されたユーザーは Users 画面に(ダッシュボードから作成したユーザーと、オンラインサインアップしたユーザー両方が)一覧表示されます:
2022090605


Auth0 側の事前準備はこれで終わりです。


【LINE Pay 側の準備】
続いて課金管理を行う LINE Pay 側の事前準備作業を紹介します。具体的にはアプリケーションを LINE Pay 連携させる際に必要な Channel ID と Channel Secret と呼ばれるキー値が必要になるので、これらを取得します。

最終的に作成したアプリで本当にユーザー課金を求める(実際のお金で決済する)場合は LINE Pay に加盟店登録が必要になります。が、今回は試験的に動作確認できればよいレベルで動かしたくて、(開発途中で)試験的に動かした際に課金してほしくもない状態です。 そのような場合向けにサンドボックスと呼ばれる開発者向け環境が用意されているので、そのサンドボックスを使って Channel ID と Channel Secret を取得し、動作確認させてみます(サンドボックス環境での決済はあくまで動作確認のための決済処理であり、実際に支払われることはありません)。

サンドボックスを使うには以下のアドレスからサンドボックス生成申請を行います:
https://pay.line.me/jp/developers/techsupport/sandbox/creation?locale=ja_JP

国(JP(日本), TW(台湾),TH(タイ)から選択)、サービスタイプ(Online)、利用通貨(JPY(日本円)かUSD(アメリカドル)から選択)、そしてメールアドレスを入力し、最後に "Submit" ボタンをクリックします:
2022090606


すると指定したメールアドレスに以下のようなメールが届きます:
2022090607


メールに記載されているテスト ID とパスワードを使って LINE Pay の加盟店 My Page にアクセス/ログインしてみます。以下のページを開いてテスト ID とパスワードを入力し、最後に「ログイン」ボタンをクリックします:
https://pay.line.me/portal/jp/auth/login

2022090608


ログイン直後は以下のような画面が表示されます。サンドボックスに移動するには画面右上の "Sandbox" と書かれたメニューをクリックします:
2022090601


サンドボックスが表示されたら、画面左のメニューから「決済連動管理」- 「連動キー管理」を選択します。連動キー管理画面でパスワードチェックの画面が表示されたら、(上述のサンドボックス申請をした時にメールで送られてきた)パスワードを入力して「確認」ボタンをクリックします:
2022090602


すると連動キー管理画面内に "Channel ID" と "Channel Secret Key" が表示されます。これらはアプリケーションを動かす際に必要になるものです:
2022090603


LINE Pay 側の事前準備もこれで終わりです。ここまでできていれば実際にサンプルアプリを動かすことができます。


【サンプルアプリの準備】
では、ここまで準備してきた
 ・PostgreSQL データベース
 ・Auth0 によるユーザー管理
 ・LINE Pay によるオンライン支払い処理
が連動する Node.js サンプルアプリケーションを実際に動かしてみます。

まずサンプルアプリケーションは Node.js 前提で作っているので、 Node.js の導入がまだであれば最初に自分の環境向けのモジュールをインストールしておいてください:
https://nodejs.org/ja/


次にソースコードを入手します。以下のリポジトリから git clone するか zip & download & unzip でソースコードを入手してください:
https://github.com/dotnsf/linepay-idaas

2022090604


このソースコードのルートフォルダに linepay-idaas.ddl というファイルがあります。この DDL ファイル(の内容)で PostgreSQL データベースのテーブル定義を行います。psql などを使って PostgreSQL に接続し、この DDL ファイルと同じ内容を実行してテーブルを定義してください(psql を使う場合は接続語に "\t linepay-idaas.ddl" コマンドで実行できます):
> \i linepay-idaas.ddl
> \q

また、このアプリケーションはいくつかの環境変数を参照して動きます。その環境変数を指定できるよう、ソースコードのルートフォルダ(app.js と同じフォルダ)内に .env というファイルを作り、以下のような内容に編集して保存してください:
LINE_PAY_CHANNEL_ID=XXXXXXXX(LINE Pay Channel ID の値)
LINE_PAY_CHANNEL_SECRET=XXXXXXXX(LINE Pay Channel Secret の値)
LINE_PAY_CONFIRM_URL=http://localhost:8080/pay/confirm(このままの値を指定)
DATABASE_URL=postgres://user:pass@xx.xx.xx.xx:5432/db(PostgreSQL データベースのアクセスURL)
PGSSLMODE=no-verify(PostgreSQL データベースにアクセスする際の SSL モードを指定、SSL を使わない場合は disable を指定)
AUTH0_CALLBACK_URL=http://localhost:8080/auth0/callback(このままの値を指定)
AUTH0_CLIENT_ID=XXXXXXXX(Auth0 Client ID の値)
AUTH0_CLIENT_SECRET=XXXXXXXX(Auth0 Client Secret の値)
AUTH0_DOMAIN=dev-xxxxxxxx.us.auth0.com(Auth0 Domain の値)

↑上で説明した PostgreSQL や Auth0、 LINE Pay で取得した値を多く使っています。設定時に取得した値を正しく入力してください。

またこちらは編集必須ではないのですが、実際にオンラインで購入する(LINE Pay で支払う)商品の情報を item.json ファイルに記載しています。この中身を編集することで、この後の動作確認時に購入する商品の名称や価格を変更することができます(デフォルト状態では以下のようになっていて、この場合は「サービス利用料金」という商品を 「100 円」で購入することになります)。必要に応じて編集して使ってください:
{
  "productName": "サービス利用料金",
  "amount": 100,
  "currency": "JPY"
}


.env ファイルと item.json ファイルの準備ができたら、後はアプリケーションの実行に必要なライブラリをインストールします。以下のコマンドを実行して、依存ライブラリをインストールします:
$ cd linepay-idaas
$ npm install

【サンプルアプリの実行】
では実際にサンプルアプリケーションを起動して、実際にログイン&支払い処理の稼働確認をしてみましょう。まずは以下のコマンドでアプリケーションサーバーを起動します(ちなみにアプリケーションサーバーを止める場合は Ctrl +C を押します):
$ npm start

アプリケーションが起動すると 8080 番ポートで待ち受けるので、ウェブブラウザから http://localhost:8080 を指定してアクセスします(実際の運用ではスマートフォンのブラウザからアクセスすることもあると思っていますが、今回は PC ブラウザを使っています)。このアプリケーションは未ログインの状態でアクセスすると、強制的にログインページに遷移するように作られているので、Auth0 のログイン画面に移動します。ここで(ダッシュボードからユーザーを作成済みであれば)メールアドレスとパスワードを指定してログインします。または一番下のリンクからオンラインサインアップすることも可能です。いずれかの方法でログインします:
2022090605


ログインに成功すると、以下のような画面が表示されます:
2022090606


画面右上にはログインしたユーザーの情報が表示されています。鍵のマークがついたユーザーは「(まだ支払い処理を行っていない)無料ユーザー」であることを示しています。またその右には Auth0 のユーザーアイコン(特に指定していない場合はデフォルトアイコン)が表示されます。なお、この部分をクリックすることでログアウトも可能です:
2022090607


また画面中央にはそのユーザー(今の状態であれば無料ユーザー)向けの内容が表示されています。現在は無料ユーザーなので、無料ユーザー向けのコンテンツと、有料ユーザーになるための支払いを行うアイコンボタン(緑の "LINE Pay" ボタン)が表示されています。後で有料ユーザーになると、この画面が変わるので確認しておいてください:
2022090608


ではこの無料ユーザーが支払い処理を行うことにします。"LINE Pay" と書かれた緑のボタンをクリックします。すると以下のような画面に切り替わります。LINE Pay での支払い処理に移るため、LINE がインストールされたスマホを使って、LINE アカウントを指定してログインするか、画面の QR コードをスキャンしてログインしてください:
2022090601


するとスマホ側には以下のような画面が表示されます。item.json ファイルで指定した内容の商品名と価格が表示され、"PAY NOW" というボタンが表示されています。この "PAY NOW" ボタンをクリックして購入します(サンドボックス環境で実行しているので、実際の決済や支払いは行われません):
2022090601


購入すると、"PAY NOW" ボタンは「決済が完了しました」というメッセージに切り替わります:
2022090602


購入処理と同時に Auth0 にログインしていたウェブブラウザの画面が自動的に更新され、以下のような内容になります:
2022090606


変わった点として、まず画面右上のアイコンから鍵マークが消えています。これは「有料ユーザー」のアイコンで、無料ユーザーから有料ユーザーへ切り替わり、そのことをアプリケーションでも認識できたことを意味しています:
2022090607


また画面中央の内容が無料ユーザー向けコンテンツから有償ユーザー向けコンテンツに変わりました。入金によってユーザー属性が切り変わったことで有償ユーザー向けの画面を表示しています:
2022090608


↑なお、この画面内には「(動作確認検証用)フリーユーザーに戻る」というリンクが表示されています。実際のアプリケーションでは有償ユーザーがわざわざ無料ユーザーに戻る、というアクションを起こしたり、そのためのリンクを用意することはないと思うのですが、今回のアプリケーションでは何度も動作確認できるよう(一度有償ユーザーになった後も、無料ユーザーに戻って実行したくなることもあると思うので)意図的にこのようなリンクを用意しています。 このリンクをクリックすると確認メッセージ後に支払いデータの削除が実行され、無料ユーザーに戻ることができます(繰り返しますが、あくまで動作確認用の機能であり、実際のアプリケーションではこのようなリンクを付けることはないと思っています):
2022090606


なお、上述の「無料ユーザー向け画面」「有償ユーザー向け画面」は、ソースコード内の views/index.ejs 内で以下のように定義しています。この部分を変更して再実行することで無料ユーザーおよび有償ユーザー向けの画面をカスタマイズすることができます。興味ある方はカスタマイズにも挑戦してみてください:
  :
  :
<div class="container">
<% if( user.type == 0 ){ %>
フリーユーザー向けコンテンツ部分<br/>
<a href="/pay/reserve"><img src="/pay_btn.png"/></a>
<% }else{ %>
有償ユーザー向けコンテンツ部分<br/>
<a href="#" onClick="userDeleteType();">(動作確認検証用)フリーユーザーに戻る</a>
<% } %>
</div>
  :
  :

緑のタグに囲まれた赤字部分が無料ユーザー向け画面青字部分が有償ユーザー向け画面として表示されます

サンプルアプリ内でログインしたユーザーが課金しているかどうかの判断を含めて実現できていると思っています。


決済処理をした後で LINE Pay 加盟店 My Page にアクセスすると、取引管理や売上管理メニューから決済内容やその ID(=トランザクションID)を参照することができます(ただこの時点では、あくまで LINE 内の取引としてしか参照できないので、「誰が」決済したかを確認することはできません):
2022090609


このアプリケーションを使って「誰が」決済したのかを参照するには、アプリケーションの PostgreSQL データベース内を参照する必要があります。PostgreSQL データベースに接続して transactions テーブル内を参照すると、トランザクション ID とユーザーID、注文 ID などが紐づけられて管理されていることが確認できます:
2022090602


ユーザーIDは(このアプリケーションの場合は)Auth0 のユーザー ID なので、ユーザーを特定したい場合は Auth0 のユーザー一覧から、この ID をキーに検索することでユーザーを特定することができます。


なお、本サンプルアプリケーションでは IDaaS として Auth0 を使っていますが、他の IDaaS でも同様に使うこともできると思います。ログインやコールバックといった処理部分は書き換えが必要だと思っていますが、ユーザーを一意に特定する ID さえ取得できれば、その ID を PostgreSQL データ内の user.id として使うことになるだけなので、比較的容易に移植できると思っています。

いかがでしょう? とりあえずこのアプリをベースに改良することで(または同等のアプリを実装することで)個人開発サービスに組み込めるレベルで Auth0 と LINE Pay を使ったウェブサービスを開発できそうな目途は立ったように感じています。


【(サンドボックス環境ではなく)実際に取引する場合の注意】
とりあえず開発環境内で実際に取引できることは確認できたと思っています。これを(画面を変えたり、商品や値段を変えたり、決済方法を変えたり、など)カスタマイズして組み込むことで、個人の作ったウェブサービスに課金機能を組み込むこともできると思っています。が、そのためには3つの課題を意識する必要があります。

1つ目は「サンドボックスではなく、正式な取引をするには LINE Pay に加盟店登録が必要になる」ことです。私自身もここは実際に試したことはなく、どのくらい大変なのか/よゆーなのか、よくわかっていません。ちょっと調べた範囲で(2022/09/06 時点の)現状では PayPay への加盟店登録も必要そうで、ちと面倒そうな印象もあります・・・ 詳しい手続きについてはこちらを参照ください:
https://pay.line.me/merchant-apply/jp/selection/login-v2

(2022/09/11 追記)
実際に加盟店登録に挑戦してみました:
http://dotnsf.blog.jp/archives/1080934049.html


2つ目は支払い方法の問題です。例えば有償で提供するサービスが1回ごとの課金であったり、初回まとめて課金後はずっと使える、というものであれば実装にも大きな問題はないと思うのですが、例えば「月額サブスクリプション」のような支払いサービスだと LINE Pay 側が未対応のように思っています(違っていたらごめんなさい)。例えば支払いのタイミングを記録しておいて、過去の同一月に支払いの記録があればその月は有償ユーザーとして扱い、支払い記録がない場合は無料ユーザーとして扱う、などの工夫をアプリケーション側で行う必要があるように思えます。


3つ目は決済手数料の問題です。おそらくこの情報が最新だと思っているのですが、デジタルコンテンツの決済手数料は 5.5% です。つまり実際に1万円売り上げた場合 550 円を手数料として LINE Pay に支払う必要がある、またこの割合はいつか変わる可能性がある、という点に留意ください。
https://linecorp.com/ja/pr/news/ja/2021/3876



(こちらを参考にさせていただきました)
https://qiita.com/nkjm/items/b4f70b4daaf343a2bedc



Auth0 のプログラミング中にちとハマった内容を備忘録メモとして残しておきます。

【背景】
ウェブのサービスやアプリを作る際に、いわゆる IDaaS(ID as a Service : ユーザー管理機能の SaaS) を使うことが多くあります。自分がよく使っているのは Auth0AppID です。ユーザーのログイン/ログアウトだけでなく、作ろうとすると面倒なオンラインサインアップの機能などもまとめて API で提供されていて、ユーザー管理周りを任せてしまうことが多いです。特に Auth0 を Node.js で使う場合は専用のライブラリも提供されていて、これを使うことで簡単に連携サービスを作っていました。

先日、Auth0 を使ってサービスの開発をしている時に「ログアウト」がうまくできないことに気付きました。以前は以下のようなコードでログアウトできていたのですが、これだとエラーは発生しないものの、セッションなのかクッキーなのか、よくわかりませんが情報が残ってしまってログアウトできていませんでした(以下のコードだとログイン情報が残ったままトップページに遷移してしまう):
app.get( '/auth0/logout', function( req, res ){
  req.logout( function(){   //. ログアウトして、
    res.redirect( '/' );    //. ログアウト後にトップページ('/')に移動する
  });
});

あれ~、以前はこのコードで動いてたんだけどな・・・ と思ってよく調べてみると、2021 年12月にログアウト処理の仕様が変わっていたようでした:
Logout Redirects Migration Guide


このあたりを踏まえて、現状の Auth0 ログアウト実装方法を調べたので、以下に記載します。

【ログアウト実装準備】
まず準備段階として、Auth0 でログアウトを行う場合に「ログアウト後に移動する先の URL」をあらかじめ登録しておく必要があります。Auth0 ログイン後の Applications メニューから該当アプリを選択した先の "Allowed Logout URLs" という項目です:
2022090401


コールバック URL 同様に、ここにログアウト後に遷移する URL を事前に登録しておかないといけないようでした。自分の場合は開発時は localhost を使うので、これと本番時の URL (https://xxxxx.xxxxxxx.com)を合わせて(カンマ区切りで)以下のように指定しました:
http://localhost:8080,https://xxxxx.xxxxxxx.com

これでログアウト処理を実装するために必要な準備は完了です。


【ログアウト実装】
現在のログアウト仕様は以下で確認できました。結論としてはクライアント(ブラウザ)が https://(Auth0 ドメイン)/v2/logout に必要なパラメータを付与して GET リクエストを出すことで正しくログアウトできるようです:
https://auth0.com/docs/api/authentication#logout

サーバーサイドのプログラム上だと以下のようになります:
app.get( '/auth0/logout', function( req, res ){
  req.logout( function(){   //. ログアウトして、
    //res.redirect( '/' );    //. ログアウト後にトップページ('/')に移動する
    res.redirect( 'https://(Auth0 のドメイン)/v2/logout?client_id=(Auth0 クライアントID)&returnTo=http://localhost:8080' ); 
  });
});

このうち、Auth0 ドメインと Auth0 クライアント ID はアプリケーションを登録する際に同時に確認/取得できるものです。また returnTo パラメータを付けないと、ログアウト処理は行われるのですが、そのまま処理が終わってしまうので、事実上 returnTo パラメータも必須です。このパラメータにログアウト後に遷移する URL を指定します。この URL は上述の準備時に Allowed Logout URLs で指定した中に含まれている必要があります(事前に指定した Allowed Logout URLs に含まれていないとエラー)。


この変更で正しくログアウトできるようになることが確認できました。ほっ・・・


このページのトップヘ