Valid for OAuth2.0 Authentication Mode only.
Under IdentityServer4 Authentication Mode, Clients are configured in the IdentityServer4 server.
The application that wants to access the API is called Client.
Before it can do so it must be authorized by the user, and such authorization must be validated by the API.
The client can be a web application, a mobile application, a desktop application, a Smart TV application, an IoT device, another API that consumed from this API, etc.
Field
|
Type
|
Description
|
New
|
Button
|
Create a Client.
|
Delete Selected
|
Button
|
Deletes selected Clients from the Database.
|
Export Selected
|
Button
|
Exports selected Clients to a JSON file.
|
Import from file
|
Button
|
Import Clients from a JSON file.
|
Pencil Icon
|
Button
|
Edit Client.
|
Trash Icon
|
Button
|
Delete Client.
|
Copy Icon
|
Button
|
Create Client by copying data from an existing Client.
|
Create/Edit/Copy Client
Each application that wants to interact with LinkarWS must identify itself as a valid client through a client_id. For this reason, clients authorized to work with LinkarWS must be registered beforehand.
LinkarWS offers the following Grant Types in OAuth2.0 mode:
•Client credentials Intended for server-to-server authentication, this flow describes an approach where the client application acts on its own behalf rather than on behalf of any individual user. In most scenarios, this flow provides the way to allow us-ers to specify their credentials in the client application, so that it can access resources under the client's control.
•Resource owner password Requires login with a username and password. In that case, the credentials will be part of the request. This flow is only suitable for trusted clients (e.g. official applications launched by the API provider).
Field
|
Type
|
Description
|
Cancel
|
Button
|
Discard changes and close the form.
|
Create/Update
|
Button
|
Save Client.
|
Client Id
|
Required
|
Public identifier for applications. It is recommended to use long and meaningless strings to avoid attacks.
|
Enabled
|
Switch
|
Enables or disables the client.
|
Flow Grant Types
|
Required
|
Indicates whether the Claim will be used for Clients, for Identity Re-sources or for both.
|
Description
|
Optional
|
An internal description for documentation.
|
Client Uri
|
Optional
|
URI to extended information about the client.
|
Logo Uri
|
Optional
|
URI to client logo
|
Client Claims Prefix
|
Optional
|
Prefix for the client's Claim Types (client_ by default).
The idea is to avoid cross-referencing with User Claims.
|
Allowed Cors Origins
|
Optional
|
Used by implementations of the default CORS policy service to build a CORS policy for JavaScript clients.
|
Enable New User EndPoint
|
Switch
|
Allows the use of the EndPoint for new user registration.
|
Enable Password Change
|
Switch
|
Allows the use of the EndPoint to change password.
|
Enable Password Recovery
|
Switch
|
Allows the use of the EndPoint to remember password.
|
Forgot Password URI Redirect
|
Optional
|
Once the Password has been changed with the Forgot Password EndPoint, the page will be redirected to the url indi-cated here.
|
Administrator email to receive notifications
|
Optional
|
Certain actions will send an email to the API administrator. In this box we indicate the administrator email address.
|
Once the general parameters are defined, allowed Scopes, Secrets and Claims must be assigned.
|
Scopes
Through Scopes we are going to filter and define the different resources allowed to the Client. You can assign any or all of the Scopes defined in the different existing ApiResources
Field
|
Type
|
Description
|
Available Scopes to add
|
Select
|
Select that allows multiple Scopes to be selected.
|
Add Scopes
|
Botón
|
Adds selected Scope(s).
|
Add All Scopes
|
Botón
|
Add all available Scopes to the list.
|
|
Secrets
A Client Secret is a secret known only by the application and the authorization server. It protects resources by granting tokens to authorized requesters .
Protect your Customer Secrets and never include them in cell phone or browser-based applications.
You can define as many secrets as you need.
Field
|
Type
|
Description
|
Description
|
Required
|
A description to identify the secret.
|
Value
|
Required
|
String that will be used as secret in the authentication token encodings.
|
Application Type
|
Required
|
String that identifies the type of application that the secret will use (app, web, etc.).
|
Expiration
|
Optional
|
A point on time when this secret will expire.
|
|
Claims
And finally we will define the Client Claims that will be passed in the token. The defined prefix will be added to the Claim name to avoid confusion with User Claims.
Field
|
Type
|
Description
|
Type
|
Required
|
Claim Name.
|
Value
|
Required
|
Claim Value.
|
Value Type
|
Required
|
String, Boolean, number or JSON value type.
|
|
