OAuth2 object - Revision history

Alexei.baranov: /* Clients */

2023-10-09T07:13:03Z

‎Clients

Alexei.baranov: /* Endpoints */

2020-06-26T07:34:02Z

‎Endpoints

Alexei.baranov at 07:29, 26 June 2020

2020-06-26T07:29:45Z

Alexei.baranov: /* Miscellaneous parameters */

2020-06-26T07:21:40Z

‎Miscellaneous parameters

Alexei.baranov: /* Web pages */

2020-06-24T05:09:36Z

‎Web pages

Alexei.baranov: /* Web pages */

2020-06-23T13:46:26Z

‎Web pages

Alexei.baranov: /* Endpoints */

2020-06-23T09:06:26Z

‎Endpoints

Alexei.baranov: /* Users */

2020-06-23T08:08:05Z

‎Users

Alexei.baranov: /* Built-in and external implementation */

2020-06-22T19:26:06Z

‎Built-in and external implementation

Alexei.baranov: /* Clients */

2020-06-22T12:59:46Z

‎Clients

@@ Line 123: / Line 123: @@
 |}
 Example:
-  "Oauth2":{
+  "OAuth2":{
      ...
      "clients": {

@@ Line 230: / Line 230: @@
 == Other settings ==
 === Endpoints ===
-i2Rest Server listens for incoming connections at several endpoints. All these endpoints has default values that can be overridden in configuration file<br/>
+i2Rest Server listens for incoming connections at several endpoints related to main or management gates. All these endpoints has default values that can be overridden in configuration file<br/>
 ''Endpoints must vary. Endpoint cannot be the beginning of another endpoint. Endpoints must be valid [https://en.wikipedia.org/wiki/URL#path URL path component]''
 {| style="width: 100%; vertical-align:top; border-collapse:collapse" border="1"
@@ Line 273: / Line 273: @@
 |-style="vertical-align:top;"
 |style="padding: 5px"|bridge_endpoint
-|style="padding: 5px"|This is [[Authorization_Code_flow_description|Bridge Endpoint]] of i2Rest Server
+|style="padding: 5px"|This is [[Authorization_Code_flow_description|Bridge Endpoint]] of i2Rest Server<br/>
 |style="padding: 5px"|
 * Authorization Code (i2Rest bridge mode)

← Older revision		Revision as of 07:29, 26 June 2020
Line 1:		Line 1:
−	~~TODO~~
	== Built-in and external implementation ==		== Built-in and external implementation ==
	Some OAuth2 parameters allow the use of a built-in (embedded) or external implementation.		Some OAuth2 parameters allow the use of a built-in (embedded) or external implementation.

@@ Line 355: / Line 355: @@
 === Miscellaneous parameters ===
-* device_request_interval
-* token_expires_in
+{| style="width: 100%; vertical-align:top; border-collapse:collapse" border="1"
-* refresh_token_expires_in
+| style="width: 10%; padding: 5px"|'''Field'''
-* revoke_token_on_change_resource_owner_credentials
+| style="width: 10%; padding: 5px"|'''Type'''
-* revoke_token_on_scope_violation
+| style="width: 40%; padding: 5px"|'''Description'''
-* PKCE_mandatory
+| style="width: 40%; padding: 5px"|'''Default value'''

@@ Line 346: / Line 346: @@
 * Authorization Code (i2Rest Bridge mode)
 |style="padding: 5px"|/pages/bridge_completed.html
 |}

@@ Line 281: / Line 281: @@
 === Web pages ===
-* login_page
+i2Rest Server at some points in the flows interacts with the user. Server installation includes the simplest versions of pages with a user interface. During the implementation process, you can change or create your own versions of pages, and specify their addresses in the configuration file.<br/>
-* decision_page
+Pages and static content can be placed and served by i2Rest Server, or you can use an external web server or web application.<br/>
-* bad_auth_page
+To place static content on the i2Rest Server, it must be placed in the <code>Static/</code> folder in the current server directory (see configuration parameter curdir). In this case, static content will be available as a resource at <code>http(s)://<i2Rest_server_name:port>/pages/<resource_path_at_Static></code>, for example:
-* enter_code_page
+ <nowiki>Static/device_connected.html => http://myserver.com/pages/device_connected.html</nowiki>
-* device_connected_page
+ <nowiki>Static/Login/index.html => http://myserver.com/pages/Login/index.html</nowiki>
-* bridge_enter_code_page
+Pages representing external links must be specified as a complete URL path in configuration file.<br/>
-* bridge_completed_page
+User interaction pages that can be specified in configuration file:
 === Miscellaneous parameters ===
 * device_request_interval

@@ Line 231: / Line 231: @@
 == Other settings ==
 === Endpoints ===
-* auth_endpoint
+i2Rest Server listens for incoming connections at several endpoints. All these endpoints has default values that can be overridden in configuration file<br/>
-* access_endpoint
+''Endpoints must vary. Endpoint cannot be the beginning of another endpoint. Endpoints must be valid [https://en.wikipedia.org/wiki/URL#path URL path component]''
-* decision_endpoint
+{| style="width: 100%; vertical-align:top; border-collapse:collapse" border="1"
-* device_endpoint
+| style="width: 10%; padding: 5px"|'''Endpoint'''
-* user_device_endpoint
+| style="width: 40%; padding: 5px"|'''Purpose'''
-* bridge_endpoint
+| style="width: 30%; padding: 5px"|'''Flows'''
 === Web pages ===
 * login_page

@@ Line 51: / Line 51: @@
 |style="padding: 5px"|boolean
 |style="padding: 5px"|User is disabled?<br/>
-Setting to "true" allows you to temporarily prevent a user from working in the system
+Setting to "true" allows you to temporarily prevent a user to take part in OAuth2 flows
 |style="padding: 5px"|false
 |}

@@ Line 1: / Line 1: @@
 TODO
 == Built-in and external implementation ==
-Some OAuth2 settings allow the use of a built-in (embedded) or external implementation.
+Some OAuth2 parameters allow the use of a built-in (embedded) or external implementation.
-* i2Rest Server Free edition allows to use built-in implementation only. This implementation uses a specific parameter structure and configuration principles. You can define the list of scopes, users or clients, set some parameters for code generation rules etc. All these parameters must be configured in the configuration file, and they will be unchanged from the moment the server starts. To change the settings, you must change the configuration file and restart the server. A detailed description of all parameters in embedded implementation is given below.
+* i2Rest Server Free edition allows to use only built-in implementation of OAuth2 parameters. This implementation uses a specific parameter structure and configuration principles. You can define the list of scopes, users or clients, set some parameters for code generation rules etc. All these parameters must be configured in the configuration file, and they will be unchanged from the moment the server starts. To change the settings, you must change the configuration file and restart the server. A detailed description of all parameters in embedded implementation is given below.
-* With i2Rest Server Premium edition, you can develop your own custom implementation of functions for working with tokens, codes, scopes, users and clients. You can use any storage for this data, any algorithms and procedures, for example, to checking passwords, to querying permissions, to define valid scopes etc.
+* With i2Rest Server Premium edition, you can develop your own custom implementation of functions for working with tokens, codes, scopes, users and clients. You can use any storage for this data, any algorithms and procedures, for example, to checking passwords, to setting and validation of permissions, to define valid scopes etc.
 == Settings for built-in implementation ==

@@ Line 83: / Line 83: @@
 === Clients ===
 === Token/Code generation rules ===
 The following parameters control the rules for generating various kinds of codes. i2Rest Server generates the following codes: