Clients

PlusAuth could be used with different type applications such as single page application, regular web applications, IoT applications, financial services, mobile applications etc.

The term Client in PlusAuth refers to the application that is attempting to get access to the user's account. For that reason, for each application you must define a client in PlusAuth.

You can manage your clients from Dashboard > Clients .

Client Types

Client types are helpers for defining an initial configuration and includes additional security layers differs from each other depending on their types.

In this section, we will describe common properties of clients.

Client Metadata

Client Name

Name of your client, could be anything. You can change it anytime. It could be used in all customizable entities such as emails and views.

Client Description

You may need additional description for your client, this field helps for that need

Client ID

Unique identifier of your client. This value is generated automatically by PlusAuth, and it will be required for almost every operation related to authentication or authorization.

Client Secret

This value must be kept confidential. Think of it as a user's password. Developers must use this value in public applications such as single page and native applications.

Logo URI

Link for your application logo. It could be used in views or emails. It is advised to use small sized logos.

Policy URI

Link for your application policy document. It could be used in views or emails.

Terms of Service URI

Link for your application's terms of service document. It could be used in views or emails.

After a user successfully logs in or authorizes your application, the authorization server will redirect the user back to the application with either an authorization code or access token in the URL. Because the redirect URL will contain sensitive information, it is critical that these URIs must belong to your application.

Post Logout Redirect URIs

After user's logs out from your application you can define a URI to redirect back. If no post logout uri used in logout request, PlusAuth will show a simple page informing user about logout process.

Grant Types

To request an access token, the client obtains authorization from the resource owner. The authorization is expressed in the form of an authorization grant, which the client uses to request the access token. Each grant type resolves to different flow and may require additional steps.

Response Types

The response types declared by the client instructs PlusAuth about the desired flow and the type of tokens and/or authorization codes the client expects to receive upon successful authorization.

Common and important values for response types include:

code: Indicates that the client is requesting an authorization code. This is the foundation of the Authorization Code Flow, which is the recommended flow for web applications as it provides better security by exchanging the authorization code for access and refresh tokens on the server-side.
id_token: Indicates that the client is requesting an ID token directly. This is part of the Implicit Flow or Hybrid Flow and is used to obtain information about the authenticated user.
token: Indicates that the client is requesting an access token directly. This is part of the Implicit Flow or Hybrid Flow.

Note: The Implicit Flow is generally discouraged for security reasons in favor of the Authorization Code Flow with PKCE.

Combinations (Hybrid Flow):

code id_token: Requests both an authorization code and an ID token.
code token: Requests both an authorization code and an access token.
code id_token token: Requests an authorization code, an ID token, and an access token.
id_token token: Requests both an ID token and an access token directly. This is a less common Hybrid Flow variant.

Token Endpoint Authentication Method

This field defines how the token endpoint should authenticate incoming request. Here is list of available values:

None: Indicates that client authentication will occur. This is for applications does not use any client secret
Post: Indicates that client authentication will occur by checking client assertion in request body
Basic: Indicates that client authentication will occur by HTTP Basic Authentication scheme
JWT: Indicates that client authentication will occur by using a JWT containing client secret.
Private Key JWT: Indicates that client authentication will occur by using a JWT containing client secret and signed by registered public key.
TLS: Indicates that client authentication will occur with mutual TLS utilizing the PKI method of associating a certificate to a client.
Self Signed TLS: Indicates that client authentication will occur using mutual TLS with the client utilizing a self-signed certificate.