マルチパーティ認証フロー

ビジネスの成功が、カスタムアプリケーションをいかに迅速に本番環境に導入できるかにかかっている場合、開発者が開発者のために設計したIAMプラットフォームが必要になります。Auth0を使用すると、高度なIDワークフローでさえも簡単に実装できるようになります。アプリケーションをより迅速かつ安全に、継続的なメンテナンスを減らして本番環境に移行する方法を見てみましょう。

B2B SaaS旅行アプリケーション、「Lodging Picks」を構築していると想像してください。これは企業に売るためのものです。ホテルや、RoomSMart （貸し部屋を所有するホストと、比較的安価な住宅風の宿泊施設を求める旅行者をマッチさせる、AirBnBに非常によく似たオンラインマーケットプレイス）など、複数のソースを集約します。課題: RoomSmartアカウントの資格情報を保持せずに、顧客のユーザーに代わって、プライベートAPI ¹ を介して RoomSmartの宿泊施設を予約する。

1. 例としてAirBnBを使用することもできましたが、同社が実際にそのようなプライベートAPIを提供しているとの勘違いを避けるため、同社の名前は使用しませんでした。RoomSmartをAirBnB のようなものと考えてください。この使用例は、現実的なマルチパーティ認証のシナリオを示しています。

このマルチパーティ認証フローの実装が複雑な理由は何か？このシナリオにおける関係者の懸念を見てみましょう。

• この企業は、ビジネスのためにLodging Picksを活用したいと考えていますが、従業員のLodging Picksアプリケーションへのアクセスを管理する必要があり、簡単に使用できるようにしたいと考えています。したがって、会社はLodging PicksをSSOインフラストラクチャに統合したいと考えており、従業員が入社および退職するときに、Lodging Picksのプロビジョニングおよびプロビジョニング解除を実行する必要があります。
• 従業員は、アプリケーションを通じて、 RoomSMart の部屋などの宿泊施設を予約したいと考えていますが、Lodging Picksが自分のRoomSmartアカウントへアクセスするのを、制御しなければなりません。特に、Lodging Picksのアクセスは、アカウントのデフォルトの支払い方法による部屋の予約のみに制限する必要があり、ホストの評価、メッセージの送信、プロフィールや支払い情報の変更に使われてはなりません。さらに、問題が発生した場合にアクセスを取り消すことができ、RoomSmartプロファイルをプライベートに保つことができなければなりません。
• Lodging Picksは、企業ユーザー向けの優れたSSOユーザーエクスペリエンスと、RoomSmart向けの新しいチャネルを使用して、企業顧客に価値のあるサービスを提供したいと考えています。しかし、セキュリティ違反が定期的にニュースとなる現代では、Lodging Picksは参加当事者に要求される信頼を保ちながら、これらの取引を仲介する必要があります。誰もが自分の貴重な情報が安全で自分の管理下にあるという安心感を持たない限り、このSaaSアプリケーションを使用するリスクが、メリットを上回る可能性があります。
• RoomSmart は、新しいB2Bチャネルを販売に加えたいと強く考えています。彼らは信頼に基づいてビジネスを構築してきました。ホストは自宅のスペースを見知らぬ人 (宿泊客) に提供し、宿泊客はサイト上の説明と他の宿泊客の評価やコメントの両方に基づいて、それらの部屋を予約します。ホストと宿泊客の両方が機密情報をサービスに保存します。RoomSmartは、プライバシーを維持し法規制を遵守しながら、同時に非常にシンプルなユーザーエクスペリエンスを提供する必要があります。そのため、RoomSmartはおそらく、他のアプリケーションにログイン資格情報を保存することを許可せず、API アクセスを厳密に制御し、機密情報の所有者が完全にそれを制御できるようにして、同社のサービスを強化する機能を保持します。

これはとても複雑です！しかし、これは独立したソースからの「API エコノミー」で、利用可能なサービスを構成することによって構築された、最新のWebおよびモバイルアプリケーションの典型でもあります。認証と承認は、そのようなサービスが本質的に信頼できない環境で、相互に信頼できるようにする方法を管理する重要なツールです。

現在、このように高度なマルチパーティ認証ワークフローをすぐに処理できるソリューションはありません。組み込みの単純な認証フローを備えたツールでは、それができません。Lodging Picksを実装するには、かなりの費用をかけてカスタムIAMソリューションを手動で構築し、専門の人材を雇用し、高価で継続的なメンテナンスを実施する必要があるでしょう。本当に必要なのはAPI主導のIDプラットフォームで、それは、開発者が柔軟性を保てるように最適化され、IDが組織間にまたがる状況においてアプリケーションを簡素化するものでなければなりません。そこでAuth0が必要になります。

ここで何が必要ですか？ユーザー (御社の顧客の従業員) は、フェデレーション企業資格情報を使用してLodging Picksにログインします。Auth0はこのプロセスを簡素化し、顧客のためにSSOを簡単に実装できるようにします。ユーザーが認証されたら、御社はLodging PicksがRoomSmart API を使用して、ユーザーに代わりRoomSmart宿泊施設を表示および予約できるようにする、オンボーディングワークフローを実行する必要があります。

企業資格情報とRoomSmart資格情報の両方を使用して、Lodging Picksにログインするようにユーザーに依頼し、アカウントをリンクして、ユーザーがいずれかのアカウントを使用してLodging Picksにアクセスできるようにしないのはなぜでしょうか？このアプローチは機能しません。ユーザーは、企業の従業員ではなくなった後でも、RoomSmart ログインを使用してLodging Picksにアクセスできます。Lodging Picksアプリケーションへのアクセスには、従業員の企業アカウントのみをSSO経由で使用する必要があります。

ユーザーにRoomSmartのユーザー名とパスワードを、 Lodging Picksアプリケーションに保存するように依頼した場合はどうなるでしょうか？これは機能するかもしれませんが、最適な方法とは言えません。RoomSmartと従業員の両方にとって安全性がはるかに低く、Lodging Picksがハッキングのターゲットになる可能性が高くなるため、RoomSmartによって許可されない可能性があります。

では、ユーザーの企業アカウントのみを使用して認証しながら、RoomSmart資格情報を保持せずに、ユーザーに代わって RoomSmartに必要なアクセスのみを取得するにはどうすればよいでしょうか？

図１ :Auth0のパイプラインルール

Auth0には強力な機能である、認証パイプラインルールが含まれており、認証が行われるたびに実行するコードを加え、カスタム処理を追加できます。ルールにはトランザクションをログに記録したり、分析プラットフォームに関連付けたり、多要素認証などの追加の認証を開始したり、追加のAPIを呼び出して追加の情報にアクセスしたり、追加の作業を実行したりできる、任意のコードを含めることができます。ルールはユーザーを外部のサイトまたはサービスにリダイレクトし、戻ったときに、その結果に対して追加の処理を実行できます。認証パイプラインに任意のコードを追加できるこの機能は、Auth0の最も強力な機能の 1 つです。

わずか数十行のJavascript で、Lodging Picksのように複雑なマルチパーティ、マルチプロトコルの認証ワークフローを実装できます。ここでは、ワークフローをルールとして実装します (プロトタイプのJavascriptコードは、このユースケースの最後にある付録Aにあります)。ユーザーが最初にLodging Picksにログインしたときなど、Auth0がまだRoomSmart の更新トークンを保存していないことがルールによって検出されると、ユーザーの認証処理が中断され、RoomSmartのAPI付与ページにリダイレクトされます。次に、ユーザーはLodging Picksに代わってAuth0に権限を付与し、ユーザー固有のAPI更新トークンを取得して、これをユーザーのプロファイルに安全に保存します。これを使用して、アクセス権が制限された短い有効期限のアクセストークンを取得できます。Lodging Picksは、Auth0のAPIを呼び出して user.app_metadata_encrypted_roomsmart_refresh_token を取得し、アクセストークンを取得した後、ユーザーに代わってRoomSmartでの検索と予約を実行することができます。ユーザーは完全にコントロールを維持することができ、RoomSmartアカウントにアクセスして、いつでもこのアクセスを取り消すことができます。RoomSmartは、更新トークンまたはアクセストークンを取り消すこともできます。別のルールでは更新トークンを自動的に使用して、古いアクセストークンの有効期限が切れる前に、新しいアクセス トークンを取得できます。

図２ :マルチパーティ認証ワークフローの例

Auth0のリダイレクトルールを使用すると、認証パイプラインを中断して任意のサービスを呼び出すことができます。これは、アプリケーションで記述したコードに限定されません。この強力な機能により、Web API エコシステムを活用したり、エンタープライズ アプリケーションへのカスタム統合を構築したりできます。

リダイレクトルールの実装方法の詳細については、Auth0の包括的なドキュメントと例を参照し、付録Aでこの特定のユースケースを実装するルールのプロトタイプをご覧ください。

任意コードの実行とは、カスタムIAMソリューションを構築及び維持することなく、複雑な認証および承認ワークフローを、柔軟に構成できることを意味します。シンプルなフックとAuth0の包括的なフロントエンドおよびバックエンドプラットフォームサポートを使用して、開発をスピードアップします。

IOSおよびAndroidのネイティブアプリケーションを実装するときが来たら、開発者はこの本番ID ワークフローを、さらに労力をかけることなく活用できます。モバイル アプリは同じ Auth0 APIを使用します。とても簡単です！

最新のWebおよびモバイル アプリケーションは、独立した企業や団体がホストするAPIが呼び出すサービスで構成されています。このAPIエコシステムの安全性は認証を頼りとします。サービス提供者は、個人を特定できる情報や、機密性の高いアクションにアクセスするためのAPIへの呼び出しが正当であり、アカウント所有者によって承認されていることを認識している必要があります。アプリケーションが複雑になるにつれ、これらの独立したAPIの使用パターンとアクセス要件を事前に予測し、確固とした設計パターンに組み込むことができなくなりました。APIエコノミーでは、認証フローを処理する際に、コード主導の柔軟性が求められます。Auth0認証パイプラインルールにより、開発者はこのようなカスタムフローを簡単に構築でき、エンドユーザーはマルチパーティ認証が必要なこれらのシナリオを、簡単にナビゲートできます。

Auth0にはもう1つのユニークな機能があります。それは、賞賛されているカスタマーサービスチームです。ヘルプはSlackのチャットまたはメールですぐに利用できます。問題を素早く解決して、ビジネスに不可欠なアプリケーションを本番環境に移行できます。

詳細については、Auth0営業チームにお問い合わせいただくか、ぜひ無料でお試しください！Auth0プラットフォームのすべての機能は、開発用の場合、常に無料です。今すぐauth0.comで無料のアカウントを作成し、開発者に焦点を当てた、その違いを発見してください。

この使用例で説明したルールを実装するサンプルコードは次の通りです。RoomSmartの同意フローを通じて認証コードを取得し、そのコードを更新トークンと交換します。次にルールはその更新トークンを暗号化し、ユーザーのプロファイルにアプリケーションメタデータとして保存します。

function(user, context, callback) {
    // If we already have the user's refresh token, don't ask for consent again.
    user.user_metadata = user.user_metadata || {};
    if (user.app_metadata.encrypted_roomsmart_refresh_token) {
        return callback(null, user, context);
    }

    var CLIENT_ID = '123456';
    var CLIENT_SECRET = 'ABCDEFG';

    // RoomSmart Webアプリケーションにリダイレクトして、同意を求めます。
    if (context.protocol !== 'redirect-callback') {
        var REDIRECT_TO = 'https://roomsmart.com';
        var REDIRECT_PATH = '/oauth2/authorize?client_id=' + CLIENT_ID +
            '&redirect_uri=http://lodgingpicks.auth0.com/continue&response_type=code' +
            '&scope=offline_access%20read_account';

        context.redirect = {
            url: REDIRECT_TO + REDIRECT_PATH
        };

        return callback(null, user, context);
    }
    // リダイレクトされます。
    else {

        // No consent given.
        if (context.request.query.error) {
            return callback(new UnauthorizedError(context.request.query.error_description));
        }

        // 同意が得られたら、認証コードをトークンに交換します
        var token_request = {
            body: 'grant_type=authorization_code' +
                '&client_id=' + CLIENT_ID +
                '&client_secret=' + CLIENT_SECRET +
                '&redirect_uri=http://lodgingpicks.auth0.com/continue' +
                '&code=' + context.request.query.code
        };
        request.post('https://roomsmart.com/oauth2/token', token_request, function(err, res, body) {
            if (err) {
                return callback(err);
            }

            var token_response = JSON.parse(body);
            if (!token_response.refresh_token) {
                return callback(new UnauthorizedError('Refresh token is missing'));
            }

            // リフレッシュトークンを暗号化します。
            user.app_metadata.encrypted_roomsmart_refresh_token = encrypt(token_response.refresh_token);

            // ユーザーのプロファイルに保存します。
            auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
                .then(function() {

                    // Continue the authentication transaction.
                    callback(null, user, context);
                })
                .catch(function(err) {
                    callback(err);
                });
        });
    }

    // 機密データを暗号化するためのヘルパー。
    function encrypt(data) {
        var iv = new Buffer(configuration.ENCRYPT_IV);
        var decodeKey = crypto.createHash('sha256')
            .update(configuration.ENCRYPT_PASSWORD, 'utf-8').digest();
        var cipher = crypto.createCipheriv('aes-256-cbc', decodeKey, iv);
        return cipher.update(JSON.stringify(data || {}), 'utf8', 'base64') + cipher.final('base64');
    }
}