メインコンテンツへスキップ

認証

Omiseはリクエストの認証にAPI keyを使用します。統合をセキュアに保つため、異なる操作には異なるkeyが必要です。

概要

OmiseはAPI keyをユーザー名として使用し、パスワードフィールドは空白のままにするHTTP Basic Authenticationを使用します。すべてのAPIリクエストはHTTPS経由で行う必要があります - プレーンHTTP経由の呼び出しは失敗します。

3種類のAPI Key

1. Public Key

用途: クライアント側の操作(ブラウザ、モバイルアプリ)

形式: pkey_test_... (テスト) または pkey_... (本番)

機能:

  • ✅ tokenの作成(カードのtokenize)
  • ✅ sourceの作成(代替決済方法用)
  • ✅ tokenとsourceの表示
  • ❌ chargeの作成(secret keyが必要)
  • ❌ アカウント情報へのアクセス

公開しても安全: はい、public keyはJavaScript、モバイルアプリ、またはHTMLなどのクライアント側のコードに安全に含めることができます。

使用例

# keyの後のコロンに注意(username:password形式で空のパスワード)
curl https://vault.omise.co/tokens \
-X POST \
-u pkey_test_5xp6c8ltm5wb5o45cls: \
-d "card[name]=Somchai Prasert" \
-d "card[number]=4242424242424242" \
-d "card[expiration_month]=12" \
-d "card[expiration_year]=2027" \
-d "card[security_code]=123"
Public Keyを使用する理由

Public keyを使用すると、クライアント側で機密データをtokenizeできるため、カード情報がサーバーに触れることはありません。これにより、PCI準拠の要件が大幅に軽減されます。

2. Secret Key

用途: サーバー側の操作

形式: skey_test_... (テスト) または skey_... (本番)

機能:

  • ✅ chargeの作成
  • ✅ refundの作成
  • ✅ customerの管理
  • ✅ transferの作成と管理
  • ✅ すべてのアカウント情報へのアクセス
  • ✅ すべての操作を実行

公開しても安全: いいえ! Secret keyは機密情報として保持し、サーバー側でのみ使用する必要があります。

使用例

curl https://api.omise.co/charges \
-X POST \
-u skey_test_5xp6c8n0jvds5mmjizz: \
-d "amount=100000" \
-d "currency=thb" \
-d "card=tokn_test_5xp6ca4dtzx5cskm9mk"
Secret Keyを秘密にする

Secret keyをバージョン管理にコミットしたり、クライアント側のコードで公開したり、公開したりしないでください。常に環境変数またはセキュアな設定管理を使用してください。

3. Chain Key

用途: サブマーチャント操作(マーケットプレイス/プラットフォームを構築している場合)

形式: ck_test_... (テスト) または ck_... (本番)

機能:

  • ✅ 接続されたサブマーチャントの代わりにリクエストを行う
  • ✅ サブアカウントのsecret keyのすべての機能

公開しても安全: いいえ! Chain keyはsecret keyと同じセキュリティで扱ってください。

Chain keyは、サブマーチャントアカウントを管理するためにOmise Connectを使用している場合にのみ関連します。ほとんどのマーチャントはchain keyを必要としません。

テストとライブのKey

各keyタイプにはテストライブの両方のバージョンがあります:

環境Public Key プレフィックスSecret Key プレフィックス目的
テストpkey_test_skey_test_開発とテスト
ライブpkey_skey_本番トランザクション
自動環境検出

Test keyはテストモードでのみ機能し、live keyはライブモードでのみ機能します。これにより、開発中の誤ったchargeを防ぎます。

Keyの場所

  1. Omiseダッシュボードにログイン
  2. 設定Keysに移動
  3. テストとライブの両方の環境のkeyが表示されます

Test Key

Test keyはサインアップ直後に利用可能です - 検証は不要です!

Live Key

Live keyは、ビジネス検証を完了すると利用可能になります。詳細については本番移行ガイドを参照してください。

API Keyの使用方法

HTTP Basic Authentication

Omiseは以下のHTTP Basic Authenticationを使用します:

  • ユーザー名: API key
  • パスワード: 空(空白のまま)

認証ヘッダー形式は次の通りです:

Authorization: Basic base64(api_key:)

API keyの後のコロンに注意 - パスワードフィールドは意図的に空のままにされています。

コード例

# Public key - tokenを作成
curl https://vault.omise.co/tokens \
-u pkey_test_YOUR_KEY:

# Secret key - chargeを作成
curl https://api.omise.co/charges \
-u skey_test_YOUR_KEY:

セキュリティベストプラクティス

すべきこと ✅

  1. 環境変数を使用

    # .envファイル
    OMISE_PUBLIC_KEY=pkey_test_...
    OMISE_SECRET_KEY=skey_test_...
  2. Keyを安全に保管

    • シークレット管理サービスを使用(AWS Secrets Manager、Azure Key Vaultなど)
    • サーバーで環境変数を使用
    • 設定でkeyを暗号化
  3. 定期的にKeyをローテーション

    • ダッシュボードで新しいkeyを生成できます
    • 古いkeyは削除するまで有効です
    • ダウンタイムを避けるためにコードを徐々に更新
  4. 異なる環境で異なるKeyを使用

    • 開発: Test key
    • ステージング: Test key
    • 本番: Live key
  5. Keyの使用を監視

    • 不正なAPI呼び出しをダッシュボードで確認
    • 異常なアクティビティのアラートを設定

してはいけないこと ❌

  1. Keyをバージョン管理にコミットしない

    # .gitignoreに追加
    .env
    .env.local
    config/secrets.yml
  2. Secret Keyをクライアント側で公開しない

    // ❌ 間違い - JavaScriptでのSecret key
    const omise = require('omise')({
    secretKey: 'skey_test_...' // ユーザーに見える!
    });
  3. Keyを公開共有しない

    • サポートチケットでkeyを投稿しない
    • メールまたはチャットでkeyを共有しない
    • スクリーンショットにkeyを含めない
  4. Keyをハードコードしない

    // ❌ 間違い
    define('OMISE_SECRET_KEY', 'skey_test_5xp...');

    // ✅ 正しい
    define('OMISE_SECRET_KEY', getenv('OMISE_SECRET_KEY'));

認証エラー

無効なKey

{
"object": "error",
"location": "https://www.omise.co/api-errors#authentication-failure",
"code": "authentication_failure",
"message": "authentication failed"
}

原因:

  • 間違ったkeyタイプを使用(publicとsecret)
  • API keyのタイプミス
  • 削除されたkeyを使用
  • Keyが環境と一致しない(テストとライブ)

解決策: ダッシュボードでkeyを再確認し、正しいkeyタイプを使用していることを確認してください。

認証の欠落

{
"object": "error",
"location": "https://www.omise.co/api-errors#authentication-required",
"code": "authentication_required",
"message": "authentication required"
}

原因: リクエストにAPI keyが提供されていません。

解決策: HTTPクライアントがBasic Authenticationヘッダーを送信するように設定されていることを確認してください。

Key管理

新しいKeyの生成

  1. ダッシュボードの設定Keysに移動
  2. 新しいKeyを生成をクリック
  3. Keyタイプを選択(PublicまたはSecret)
  4. すぐに新しいkeyをコピー(後で取得できません)
  5. アプリケーションコードを更新
  6. 古いkeyを削除する前に徹底的にテスト

Keyの削除

  1. まず新しいkeyを生成してデプロイ
  2. すべてのサービスが新しいkeyを使用していることを確認
  3. ダッシュボードから古いkeyを削除
  4. 認証エラーを監視
Keyの削除

Keyを削除すると、すぐに無効になります。削除前に、どのサービスもkeyを使用していないことを確認してください!

FAQ

モバイルアプリでsecret keyを使用できますか?

いいえ! モバイルアプリのコードは逆コンパイルされ、secret keyが公開される可能性があります。常に:

  • モバイルアプリでpublic keyを使用
  • tokenをサーバーに送信
  • サーバー側でsecret keyを使用してchargeを作成

適切な実装については、モバイルSDKガイドを参照してください。

テストからライブモードにどのように切り替えますか?

コード内でtest keyをlive keyに置き換えるだけです:

// 変更前:
const omise = require('omise')({
secretKey: 'skey_test_...'
});

// 変更後:
const omise = require('omise')({
secretKey: 'skey_...' // "_test_"プレフィックスなし
});

統合コードはまったく同じままです!

Keyが侵害された場合はどうすればよいですか?
  1. すぐに: ダッシュボードで新しいkeyを生成
  2. 削除: 侵害されたkeyを削除
  3. 更新: すべてのサービスを新しいkeyで更新
  4. 監視: 不正なchargeのアカウントを監視
  5. 連絡: support@omise.coに事件を報告

次の場合は、予防策としてkeyをローテーションすることをお勧めします:

  • Keyアクセス権を持つ開発者が退職
  • セキュリティ侵害の疑い
  • Keyが誤って公開リポジトリにコミットされた
複数のkeyセットを持つことができますか?

各アカウントには、1セットのtest keyと1セットのlive keyがあります。ただし、以下が可能です:

  • いつでもkeyを再生成(古いkeyは有効なまま)
  • 異なるブランド/ビジネス用に複数のOmiseアカウントを作成
  • Omise Connectでサブアカウントを使用(プラットフォーム用)
Keyは期限切れになりますか?

いいえ、API keyは自動的に期限切れになりません。ただし、以下をお勧めします:

  • 定期的にkeyをローテーション(6〜12か月ごと)
  • アクセス権を持つチームメンバーが退職した際に新しいkeyを生成
  • 侵害された場合は直ちにkeyを置き換える
vault.omise.coとapi.omise.coの違いは何ですか?
  • vault.omise.co: tokenization用にpublic keyと共に使用(カードデータを安全に保つ)
  • api.omise.co: 他のすべての操作用にsecret keyと共に使用

この分離により、機密のカードデータがサーバーやメインAPIに到達しないことが保証されます。

関連リソース


質問がありますか? support@omise.coにお問い合わせいただくか、詳細なエンドポイントドキュメントについてはAPIリファレンスを確認してください。