omn​​iauthおよびrailsでのシングルサインオン

GoogleやEnvatoなどのエコシステムでのユーザー認証は、クライアントサイトに必要なデータとトークンを提供する個別のサービス（ accounts.google.com 、 account.envato.com ）として実装されます。 Ruby on Railsでのいくつかのプロジェクトの開発中に、私は同様の問題に対処しなければなりませんでした。 科学的に- シングルサインオンまたはシングルサインオン テクノロジー 。



必要なのは、（1）すべての生態系サイトに共通のサービスであり、（2）「ログイン+パスワード」リンクを使用してログインするための、主に社会的許可です。

（3）ユーザーがシステムにログインするためのソーシャルサービスからのデータをそれ自体に蓄積し、（4）このデータをクライアントサイトに提供するサービス。



タスクは非標準と同じくらい興味深いものでした。 それはすべて有用だが少し時代遅れの記事から始まりました-著者は、omniauth gemと、クライアントサイトおよびプロバイダーサイトで、同じomniauthをソーシャルネットワークを介した認証のための工夫と組み合わせて使用​​することを提案しました。 サービス。



私の場合、工夫はうまくいきませんでした（ユーザー名+パスワードと結びつける）ので、omniauthが完全に優先されました。 これが私の小さな冒険の始まりです。その過程で、この記事をよく理解することをお勧めします。

一般的なスキーム

クライアント サイト 、 サイトプロバイダー、およびomn​​iauthカスタム戦略の 3つのプロジェクトが検討されます 。 リンクはすべてgithubで利用可能であり、すぐに使用できます。 記事では重要なポイントのみが取り上げられます。

クライアントサイト

localhost：4000で実行します。

構造は、omniauthを使用するすべてのサイトの標準です：

• Gemfileでは、omniauthとomniauth-accounts戦略を接続します。

gem 'omniauth' gem 'omniauth-accounts'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• バンドルインストール
• config / initializers / omniauth.rbで、初期化コードを挿入します。

 Rails.application.config.middleware.use OmniAuth::Builder do provider :accounts, ENV['ACCOUNTS_API_ID'], ENV['ACCOUNTS_API_SECRET'], client_options: { site: ENV['ACCOUNTS_API_SITE'] } end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• router.rbで、コールバックメソッドのルートを追加します。

 match '/auth/:provider/callback', :to => 'auth#callback'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• コントローラーとその中にコールバックメソッドを作成し、そこでrequest.env ['omniauth.auth']を介してデータとトークンを含む最終ハッシュを取得します

 rails g controller auth --skip-assets # auth_controller.rb class AuthController < ApplicationController def callback auth_hash = request.env['omniauth.auth'] render json: auth_hash end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最低限、これですべてです。

戦略

標準のoauth 2.0戦略から派生したomniauth-oauth2依存関係は、Gemspecで指定されています。 コードはほとんどありませんが、自分で調整することは意味がありません。必要な戦略はすべて初期化パラメーターで送信されます（この例では、環境変数の形式で）。 これは：

• クライアントサイトのサイトプロバイダーに接続するための資格情報キー（ACCOUNTS_API_IDおよびACCOUNTS_API_SECRET）
• プロバイダーのサイトアドレスACCOUNTS_API_SITE
• プロバイダーサイトの認証アドレス（デフォルト：/ authorize）..
• ...トークン（/トークン）を取得する

このデータを受け取った後、戦略はさらにすべての作業を引き受けます。 ただし、このため、特定の状況で戦略が「失われた」場合、開発中に不快なケースが発生する可能性があります。計画どおりに実装を続行できません。 私はそのような問題に直面しなければならず、それぞれの解決策が見つかりました-記事の後半で説明します。

ウェブサイトプロバイダー

localhost：3000で実行します。

2つの半分を組み合わせます。

• 1つは、クライアントサイトとの通信用です
• もう1つは、ソーシャルサービスとの通信用です。

プロバイダーサイトでの認証は、標準のomniauth戦略を使用して行われます。

クライアントサイトでの認証-カスタム戦略を使用します。



共有リンク-アカウント：

• プロバイダーサイトのエントリメソッドはそれに関連付けられています（ハブのハウスキーパーのように）
• クライアントサイトの申請と助成金もそれに関連しています。

プロバイダーのサイト認証とアカウント管理

クライアントサイトに登録するとき、FacebookまたはTwitterのプロファイルから、必要なフィールドのほとんどに自動的に入力するのは楽しいことです。 私たちのウェブサイトプロバイダーはアグリゲーターの役割を果たします-ソーシャルネットワークからすべてのデータを集約させます。 サービスは1つのアンケートに記入します。これは手動で補足でき、クライアントサイトはそこから情報を取得します。



このトピックは、すでにHabrのページに掲載されています。 残念ながら、私はこの記事を見つけることができませんが、特に、サイトでのソーシャル認証に関する典型的な問題についての質問が提起されました。

• アカウント統合オプション
• サービスで更新するときにアカウントデータを更新する
• 1つのアカウントに異なるサービスをバインドする機能

これらはすべて、このタイプのシステムの典型的な要件であり、電子メールでの電子メール送信の検証-ログイン+パスワードによる認証で開発された従来の要件です。 これらの要件を簡単に検討します。

アカウントの統合

gmail-boxを介してシステムに入りました。システムは、gmailからのデータを使用して1つのアカウントを作成しました。 次回Facebook経由でログインすると、システムは再び新しいアカウントを作成しました。 最後に、自分用のアカウントを作成したときに...覚えておいてください... gmail！ ボタンをクリックすると、今度はgmailを通過し、アカウントが1つにマージされます-2ペニーのように！..またはそうでない-1つの問題があります。 データのマージ。



gmailで私たちはAlexander Polovinであり、facebookではAlex Polovinです。 また、アカウントにはどのデータを残す必要がありますか？



マージ中にすぐに、これから何を残すかをユーザーに尋ねますか？ いいえ、これは使いやすさの点で非常に成功していません-結局、ユーザーは以前にアクセスしたサイトにアカウントですぐに再度ログインするためにアカウントをマージします。



私の決定は、アカウントフィールドの追加値として「予備の」新しいデータを追加することでした。 実際、すべてのアカウントデータはハッシュに保存され、このハッシュはマージ後に次の形式をとることができます（条件付きtwitterからデータを追加する-Half Alex）：

 { name: [' ', 'Alex Polovin', ' '], first_name: ['', 'Alex', ''], sir_name: ['', 'Polovin'], ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、値は各フィールドの配列に単純に追加されます。 ただし、それらは複製されません。Twitterの「Half」は「last name」に複製として保存されませんでした。



クライアントサイトは常に配列から最初の値を受け取ります。必要に応じて、ユーザーは最初の場所に任意の値を配置できます。

アカウント情報を更新する

ソーシャルからomniauthで利用可能なすべてのデータの中で。 サービスの場合、ユーザーのアバターはほとんどの場合更新されます。 あまり頻繁ではない-ページへのリンク（urlsパラメーター）、Twitterのニックネームと説明。 いずれにせよ、ワンクリックであなたのアカウントを更新したい、または古いものを残したい-結局のところ状況は異なります。 アルゴリズムはこれに最適です-重複を保存せずに新しい値を配列の最後に書き込みます。

異なるサービスを1つのアカウントにリンクする

ハブ上の家政婦の類似物-システムでは、認証テーブルにエントリが作成され、現在のアカウントに添付されます。 将来、キーおよびデータソースとして使用されます。

アカウントフィールドの手動編集

すべてのフィールドがソーシャルから入力されるわけではありません。 サービス。 ユーザーは、プロバイダーのWebサイトのページで、不足しているデータを自分で入力できる必要があります。 また、配列内の値を交換するには、上記のいくつかの段落で言及しました。

実装

モデル

• アカウント-データハッシュを保存します（情報）
• 認証-Facebook、Twitter、または別のサービスでomniauthを介して実行される認証。 プロバイダーの名前とユーザーuidを保存します。

Railsが情報をハッシュとして理解するために、テキストフィールドのタイプが移行で指定され、コードがモデルに追加されます。

 serialize :info, Hash
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

モデル間-1対多の関係：

 # /app/models/account.rb has_many :authentications # /app/models/authentication.rb belongs_to :account
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コントローラー

AuthenticationsControllerはすべての認証ニーズをカバーし、次のアクションが含まれます。

• auth（/ auth）-ログインまたはプロファイルデータを更新するサービスを選択するページ
• ログアウト（/ logout）-ログアウト
• コールバック（/ auth /：プロバイダー/コールバック）-このメソッドでは、データの入力、更新、認証のバインドなどの主要な作業が行われます。
• failure（/ auth / failure）-入力時に「相手側」でエラーが発生した場合に実行されます
• detach（/ auth / detach）-現在のアカウントから認証を切断します

認証サービスの1つを選択すると、omniauthの標準である操作が実行されます。認証の成功の場合、その中核はコールバックメソッド呼び出しです。 状況に応じて、次のアクションを実行します。

• プロファイルデータを更新します
• 2つの異なるアカウントをマージします
• 新しいサービスを現在のアカウントにバインドします
• 再ログインまたはプライマリログイン

データハッシュは、選択したソーシャルネットワークに応じて、個別のプライベートメソッドget_data_hash（）で形成されます。 サービス。



重複することなく配列の最後にデータを追加するには、add_infoモデルメソッドを使用します（配列の結合操作に基づいて）。

 def add_info(info) self.info.merge!(info){|key, oldval, newval| [*oldval].to_a | [*newval].to_a} end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

認証add_authenticationsをバインドするには：

 def add_authentications(authentications) self.authentications << authentications end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、セッションはログインしたアカウントのID（セッション[：account_id]）を保存します。



この段階のAccountsControllerには、次のアクションが含まれています。

• index-フォーム内のユーザープロファイル
• 編集-アカウントプロファイルデータの編集
• 更新-プロファイルを更新します（編集からのPOST要求）

また、フィルター-ネットワーク上のユーザーの存在の必須チェック（ログインログインページへのリダイレクト付き）。



本当に便利で柔軟なデータ変更の可能性を実現したかったのです。 そして、そのようなタスクはまだ残っており、将来解決されるでしょう。 これまでのところ、編集は2つの方法で行われます。

• jsが無効になっている場合-YAML形式のハッシュを持つテキスト領域があります
• 有効にすると、json構造jsoneditorのビジュアルエディターがロードされます。

クライアントサイトとプロバイダーサイト間のリンクの作成

この場合、標準的な方法は、プロバイダーのWebサイトで「アプリケーション」を作成することです。 クライアントサイトの名前とアドレス（または、コールバックリダイレクトのアドレス）を示します。2つのキーidとsecretを取得します。 ソーシャル認証システムのパラメーターでそれらを示します-cmsプラグインでも、Railsのgemでも。 この場合、キーはomniauth-ACCOUNTS_API_IDおよびACCOUNTS_API_SECRETによって使用されます。



Webサイトプロバイダーでのアプリケーションサポートの実装は簡単です。

 rails g scaffold Application name:string uid:string secret:string redirect_uri:string account_id:integer rake db:migrate # account.rb has_many :applications
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しいレコードを作成するとき、モデルはそのためのキーを生成する必要があります。

 before_create :default_values def default_values self.uid = SecureRandom.hex(16) self.secret = SecureRandom.hex(16) end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして-アプリケーション上のすべてのアクションは、現在のユーザーによってフィルターされる必要があります。 たとえば、次の代わりに：

 @applications = Application.all
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

使用者：

 @applications = Account.find(session[:account_id]).applications
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、ユーザーがオンラインであることを確認することが不可欠です-フィルターを配置します。

 before_filter :check_authentication def check_authentication if !session[:account_id] redirect_to auth_path, notice: '    ,    .' end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロセス図

認証はoauth 2.0に基づいています-このプロトコルの原理については、ハブに関するこの記事で、またはここで明確に学ぶことができます。



出発点は、アドレスclient-site.com/auth/accountsです。 Omniauthはそれを取得し、omniauth-accounts戦略を使用して、プロバイダーのサイトのサーバーにリクエストを送信します。



同時に、omniauthは状態パラメーターを生成します。これは、プロバイダーが1つのクライアントサイトからのリクエストとユーザーを他のリクエストと混同しないようにするのに役立ちます。



Webサイトプロバイダーは要求を受け入れ（標準では、provider-site.com / authorizeで）、特定のアクションを実行します。 この段階でのプロバイダーの目標は、ユーザーを承認し、クライアントのサイトで認証のための許可を与えることです。



目標が達成されると、リダイレクトがクライアントサイトのコールバックメソッドに送信され、そこからrequest.env ['omniauth.auth']がプロバイダーサイトからトークンとデータを含むハッシュを取得します。

ログイン

authorizeメソッドは、プロセススキームで最も暗い場所です。ユーザーに許可を与える前に考慮すべき微妙な違いがたくさんあります。



理想的には（繰り返し承認される場合）-次の条件が満たされます。

• ユーザーは既にプロバイダーサイトにログインしています
• ユーザーには、以前にこのアプリケーションの許可が既に与えられています
• この許可は期限切れではありません

この場合、ユーザーはすぐにログインし、クライアントサイトのコールバックメソッドへのリダイレクトが実行されます。 パラメータは許可コードと状態stateを送信します。



これらの条件の少なくとも1つが満たされない場合、最初に問題を解決する必要があります。

• ユーザーがプロバイダーのウェブサイトにログインしていない場合は、ログインさせます
• 許可が発行されていない場合は、作成します。
• 許可の期限が切れている場合は、許可を再作成します

これらのアクションには、サイトプロバイダーやソーシャルサイトのナビゲートも含まれます。 サービス（ユーザーがログインする必要がある場合）。 最後の理由が明らかになりました-この場所で、omniauthは不快な側面を示しています。



事実、omniauthは、承認に切り替えると、URLにいくつかのパラメーターを渡し、プロバイダーサイトのセッションでいくつかのパラメーターを指定します。 これは、彼がコールバックメソッドに正しくリダイレ​​クトするために必要です。 ただし、プロバイダーサイトで突然omniauthを使用したい場合（たとえば、ソーシャルサービスを介してログインしようとした場合）、omniauthはセッションからデータを消去します。 また、リダイレクトはエラーOmniAuth :: Strategies :: OAuth2 :: CallbackError-invalid_credentialsで失敗します。



したがって、このような状況を回避するために、すべてのomniauthパラメーターはセッションで明確に修正され、リダイレクトの直前に復元されます。

注文＃登録

すべてのパラメーターが正しく送信された場合（つまり、要求がomniauthから送信された場合）-現在のセッションでレコードを作成します-「注文を許可」し、すべてのパラメーターを保存します。

 session[:grants_orders] = Hash.new if !session[:grants_orders] session[:grants_orders].merge!( params[:client_id] => { redirect_uri: params[:redirect_uri], state: params[:state], response_type: params[:response_type], 'omniauth.params' => session['omniauth.params'], 'omniauth.origin' => session['omniauth.origin'], 'omniauth.state' => session['omniauth.state'] } )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

注文番号

ここですべてのチェックを実行します。 ユーザーはオンラインですか、リクエストの送信元のサイトにアプリケーションが登録されていますか、古い許可がありますか、有効期限が切れていますか。

• すべてが正常な場合、すぐにgrantメソッドを呼び出します
• 何かが間違っている場合、そのような認証に典型的なページを表示します（「アプリケーションはアカウントへのアクセスを要求しています」、「許可」、「拒否」）

注文＃受け入れる

許可がすぐに利用可能で要件に一致した場合、または許可注文ページの「許可」ボタンをクリックして実行されます。

• セッションに保存されたすべてのomniauthパラメーターを復元して、コールバックメソッドにリダイレクトするときにomniauthによって適切に処理されるようにします
• 許可を作成してリダイレクトする

注文＃拒否

アプリケーションをキャンセルし、セッションから削除するだけです。

＃トークンを付与

渡されたパラメーターに従って、アプリケーションと許可を見つけます。 すべてが正常である場合、json形式で許可トークンを発行します。

アカウント＃get_info

合意に基づいて、ハッシュをjson形式で返します-配列で表される場合、最初のパラメーター値のみ。

 data_hash = grant.account.info hash = Hash.new hash['id'] = grant.account.id data_hash.each do |key, value| if value.kind_of?(Array) hash[key] = value[0] else hash[key] = value end end render :json => hash.to_json
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おわりに

ソリューションはシンプルであることが判明しました。その中で、多くの点を改善および最適化できます。 現在、次のタスクの概要が示されています。

• アプリケーションを作成するときに、必要なパラメーターを正確に示す機会を与えることは必須およびオプションです。 また、必要なパラメーターがユーザーのプロファイルにない場合-助成金受領ページで直接入力する機会をユーザーに与えます
• ユーザー名とパスワードのリンクでログインを提供する-omniauth-identity戦略を使用して
• クライアントサイトだけでなくプロバイダーサイトでもログアウトするログアウトアクションをクライアントサイトに追加します
• tosonおよびget_info jsonリクエストでセッションが失われる問題を解決します（これは、Railsセキュリティシステム、protect_from_forgeryおよびverify_authenticity_tokenに何らかの関係があるようです）

毎日このようなシステムを作成する必要はありません。実際、インターネットにはそれほど多くのエコシステムが存在しないためです。 Google、Envato、Yandex、Yahoo-そして他に誰が？ おそらくあなたのプロジェクト？ そして、これが関連プロジェクトに認証を実装する唯一の方法ではありません-CASテクノロジー（いくつかの便利なリンク）、OpenID（そしてオプションとして同じLoginza）があります。 私たち自身のhabrおよび他のTMプロジェクトでは、一般に、各サイトに個別の認証システムと独自の「キーマスター」があります。



SSOを選択した理由は何ですか？ おそらく「ため」の鍵は雰囲気です。 これらは、ユーザーがサイトではなくシステムにログインしたときに経験する感情です-大文字の「C」で。 強力で先進的な開発されたシステムへ-これは本当に驚くべき感覚です、同僚。