Login Client Configuration

The default configuration for the Login Client works right out of the box for local development and all Login Scopes are enabled by default. The minimum viable configuration for the Login with Unstoppable client is the client ID and redirect URIs, which is established in the Client Metadata section (Step 2 below).

Step 1: Add a New Client to Your Account

• Visit the My Clients page to view all of the clients associated with your wallet address.
• Take any of the following actions on this page:
  • Click Change Wallet button to signin with a different wallet and see clients associated with a different wallet address.
  • Click the gear to modify an existing client configuration.
  • Click the trash can to delete or remove a client from your account.
  • Click Create Client button to add a new client.

Step 2: Client Metadata Configuration

The Client Metadata section includes the unique client ID and redirect URIs. Developers can also download metadata for the existing client configuration from within this sub-section.

Rules for Redirect URIs

The Redirect URIs follow three rules:

1. http URIs must resolve to URIs hosted at http://127.0.0.1 or http://localhost .
2. URIs hosted at http://127.0.0.1 do NOT require the port to be specified. All other URIs (including those hosted at http://localhost ) require the correct port to be specified.
3. All https URIs specified must use the same origin (e.g. https://unstoppabledomains.com/redirectUri1 , https://unstoppabledomains.com/redirectUri2 )

Step 3: Cosmetic Configuration (Optional)

The Cosmetic Configuration allows developers to customize the UI to improve the user experience. This includes updating or modifying the client name presented to the user, client URI, logo URI, policy URI, and terms of service URI.

The following table describes the fields for the cosmetic configuration UI section.

Step 4: Advanced Configuration (Optional)

The Advanced Configuration includes options for CORS, audience URIs, grant types, response types, scopes, and token endpoint auth method.

The following section describes the fields for the advanced configuration UI section.

Allowed CORS Origins

CORS is a browser protocol for accessing info from another domain. If a URI is entered, CORS is enabled for all requests from that client. Developers can enter the origin URI and specify the port. The Token, UserInfo, and Revocation endpoints all respect this option.

Audience URIs

These URIs represent the audience that is inside the access token JWTs. You get back an access token and ID token and both are JWTs. The access token is opaque.

• For the ID token, the audience are the clientIDs.
• For the access token, the audience is the resource servers; those resource server URLs are the audience for the access token.

Grant Types

There are two ways to request an access token: authorization code and refresh token.

• auth code: short lived, used to initially get the session with the user, corresponds to authorization\ code grant type_
• refresh token: lives longer, used to maintain a session, receive an extra token to re-authenticate users later for a certain period of time, corresponds to the offline grant type

Response Types

There are three response types: authorization code, access token, ID token.

• auth code: more secure; returns authorization code which you exchange for authorization
• access token: implicit flow, not recommended because it is less secure; no code but you receive ID or access token
• ID token: hybrid flow; receive all three: access code, access token, and/or ID token

Scopes

All scopes are turned on by default. To limit the scopes that the application can request, simply uncheck or disable those scopes.

• wallet maps to the wallet scope
• email maps to the email scope
• email:optional maps to the email:optional scope
• humanity_check maps to the humanity_check scope
• humanity_check:optional maps to the humanity_check:optional scope

Token Endpoint Authentication Method

This setting configures how to send the client secret to the authorization server after you receive the authorization code; can be enabled for an extra layer of security but can only be used if your application can store secrets (e.g., node.js integrations). The client secret is stored on server as a hash, so authorization server doesn't actually know the client secret. See additional resource for Client Basic and Client Secret oAuth.

• client secret basic: uses http basic authentication to send over clientid:clientsecret inside the header, which is base64 encoded.
• client secret post: uses http POST authentication to send over client _ secret parameter inside the body.

Step 5: Save Changes

You must save any changes made to the configuration options before they will take effect. For enhanced security, any changes made to update the application requires a wallet connection and signature.