OutSystems Forge 日本語データベース

SocialLogin

※Forge全件データの日本語検索サービスをご利用になりたい場合は、こちらまでお問合せください。

Forge英文サイト

2017-03-07 1.0.0 Raul Serôdio 10.0.200.2 All All Connectors
複数のOAuthプロバイダのドラッグアンドドロップによる簡単な認証メカニズム ID、名前、電子メールなどの基本的なユーザー情報を取得します。
このコンポーネントは、Facebook、GitHub、Googleなどの複数のOAuthプロバイダに対してユーザーを認証するための簡単なドラッグ&ドロップメカニズムを提供します。 利点 エラー処理機能を備えたオールインワンのOAuth認証。使いやすい、ウェブブロックドラッグ&ドロップファッション。 Basic / OAuthの知識は必要ありません(プロバイダでAPPを作成して設定する必要があります)。 CSRFチェック、認証、RESTメカニズム、スコープなどのOAuth実装の詳細への抽象化。 サポートされているプロバイダは何ですか? 今のところFacebook、GitHub、Google、Instagram、Linkedin。 どのユーザー情報がプロバイダから取得されますか? 指定したスコープに応じて、基本情報(ユーザーID、名前、電子メール)のみが取得されます。 スコープは静的なエンティティなので、エンドレスで標準化されていないプロバイダのスコープリストを心配する必要はありません。 セキュリティ CSRFチェックが実施されている。機密データに関しては、一回の使用のためにアクセストークンのみがセッションに格納されます。アプリ秘密やクライアントIDのような他の機密データが入力設定パラメータとして渡されます。 承認ヘッダーは、すべてのREST呼び出しで使用されます。 フィードバック これをより良いコンポーネントにするために、ご意見やご提案をお寄せください。 OAuthの概要(http://tutorials.jenkov.com/oauth2/overview.htmlから変更) 最初に、ユーザーはクライアントWebアプリケーション(この場合はSocialLoginDemo)にアクセスします。このWebアプリケーションには、「Facebook経由のログイン」(またはGoogleやTwitterなどの他のシステム)というボタンがあります。 第2に、ユーザがログインボタンをクリックすると、ユーザは認証アプリケーション(例えば、Facebook)にリダイレクトされる。その後、ユーザーは認証アプリケーションにログインし、認証アプリケーション内のデータへのアクセスをクライアントアプリケーションに許可するかどうかを尋ねられます。ユーザーは承認または拒否します。 第3に、認証アプリケーションは、クライアントアプリケーションが認証アプリケーションに提供したリダイレクトURIにユーザをリダイレクトします。。 このリダイレクトURIを提供するには、通常、クライアントアプリケーションを認証アプリケーションに登録する必要があります。 この登録中、クライアントアプリケーションの所有者はリダイレクトURIを登録します。 この登録中に、認証アプリケーションはクライアントアプリケーションにクライアントIDとクライアントパスワードを与えます。 URIには認証コードが付加されます。 このコードは認証を表します。 第4に、ユーザは、クライアントアプリケーション内のリダイレクトURIに位置するページにアクセスする。 バックグラウンドでは、クライアントアプリケーションは認証アプリケーションに接続し、クライアントID、クライアントパスワード、およびリダイレクトリクエストパラメータで受信した認証コードを送信します。 認証アプリケーションはアクセストークンを返します。 クライアントアプリケーションがアクセストークンを取得すると、このアクセストークンをFacebook、Google、Twitterなどに送信して、ログインしたユーザーに関連するこれらのシステムのリソースにアクセスできます。

[Overview]
Simple drag and drop authentication mechanism for multiple OAuth providers. Retrieves basic user info like id, name and email.
[Detail]
What is this? This component provides you with an easy drag and drop mechanism to authenticate an user against multiple OAuth providers like Facebook, GitHub, Google... Benefits All in one robust OAuth authentication with error handling. Easy to use, web block drag and drop fashion. Basic/no OAuth knowledge required (you will still need to create and configure the APP at the provider). Abstraction to OAuth implementation details like CSRF check, authentication, REST mechanisms and scopes. What are the supported providers? For now, Facebook, GitHub, Google, Instagram and Linkedin. What user info is retrieved from providers? Only basic information is retrieved, i.e., user ID, name and email, depending on the Scope you specify. The Scope is a static entity, there is no need for you to worry about endless and unstandardized provider scope lists. Security CSRF checks are implemented. As for sensitive data, only access tokens are stored in Session, for a one time usage. Other sensitive data like app secrets and client id's are passed as input configuration parameters. Authorization header is used in all REST calls. Feedback Please feel free to drop your feedback and suggestions to make this a better component. OAuth Overview (adapted from http://tutorials.jenkov.com/oauth2/overview.html) First the user accesses the client web application (in this case SocialLoginDemo). In this web app there is a button saying "Login via Facebook" (or some other system like Google or Twitter). Second, when the user clicks the login button, the user is redirected to the authenticating application (e.g. Facebook). The user then logs into the authenticating application, and is asked if she wants to grant access to her data in the authenticating application, to the client application. The user accepts or denies. Third, the authenticating application redirects the user to a redirect URI, which the client app has provided to the authenticating app. Providing this redirect URI is normally done by registering the client application with the authenticating application. During this registration the owner of the client application registers the redirect URI. It is also during this registration that the authenticating application gives the client application a client id and a client password. To the URI is appended an authentication code. This code represents the authentication. Fourth, the user accesses the page located at the redirect URI in the client application. In the background the client application contacts the authenticating application and sends client id, client password and the authentication code received in the redirect request parameters. The authenticating application sends back an access token. Once the client application has obtained an access token, this access token can be sent to the Facebook, Google, Twitter etc. to access resources in these systems, related to the user who logged in.
戻る