Managing Client and Scopes

R-Auth allows administrators to manage OAuth2/OIDC clients and their respective scopes. This functionality enables seamless integration of various applications, defining access control, authentication, and authorization through granular scope management. This system ensures secure client-server communication by leveraging standardized protocols.

1. Client Management

R-Auth allows the configuration of OAuth2 clients, enabling external applications to securely interact with the system. Each client can have custom configurations for login, access tokens, and authorization endpoints.

Client Information:

• Client Name: The display name of the client (e.g., "ECAM Client").

• Client ID: A unique identifier assigned to each registered client, used during OAuth2 authorization requests.

• Client Secret: The secret associated with the client for secure communication. Administrators can regenerate or hide this secret for security purposes.

Client Settings:

• Authentication Method: When creating or updating a client, you can select from these authentication methods based on your security and application requirements.

• Basic Header is recommended for backend or server-side applications that can securely handle a client secret.

• Public Client is preferred for frontend or mobile applications that cannot store sensitive data like client secrets.

• Body Param can be used in situations where headers cannot be manipulated, but administrators should be cautious due to the reduced security compared to headers.

• Scopes: Defines the permissions requested by the client. Common scopes include email, roles, openid, profile, and others, allowing fine-grained control over user data access and actions.

• Trusted Client: If checked, this indicates that the client is trusted and has access to extended permissions.

• Auto Approve: When enabled, user consent prompts are automatically approved for this client.

URLs and Redirect Endpoints:

• Login URL: The URL to which the user is redirected for login (e.g., http://authprovider.url/loginservice).

• Logout URL: The URL to which the user is redirected when logging out or ending the session.

• Redirect URIs: The callback URLs that OAuth2 will use after authentication. Multiple redirect URIs can be defined, allowing different environments (e.g., development, production).

  • Example: http://localhost:4200/rube/callback.

These URLs must be configured to ensure the secure flow of tokens between the client application and R-Auth.

2. Token Settings

Administrators can configure token lifetimes and other security-related settings to ensure a balance between security and usability.

• Access Token Validity: The time in seconds for which the access token remains valid. Default: 3600 seconds (1 hour).

• Refresh Token Validity: The time in days for which the refresh token remains valid, allowing users to extend their sessions without re-authentication. Example: 24 hours.

• Revoke on Refresh: If enabled, it ensures that each refresh token is used only once, enhancing security by preventing token reuse.

3. Advanced Settings

• Enable PKCE: Proof Key for Code Exchange (PKCE) enhances OAuth2 security, especially for public clients. When enabled, the client must provide a code challenge and verifier during the authorization code flow.

• Token Binding: This option enhances security by binding issued tokens to certain client parameters, reducing risks of token theft.

4. Scope Management

R-Auth provides a Scope Management section that enables administrators to define the permissions or data a client can request during the authentication and authorization process.

Scopes:

• email: Grants access to the user’s email information.

• openid: Required for OIDC (OpenID Connect) to obtain the user’s identity information.

• profile: Provides access to basic user profile information (name, profile picture, etc.).

• roles: Grants the client access to the user's assigned roles, allowing role-based access control for external applications.

Scopes are critical to ensure that each client is only granted the necessary permissions to interact with user data and perform actions. The administrator can define default and optional scopes based on the client’s requirements.

5. Client Actions

R-Auth allows the following actions to manage clients and their tokens:

• Update: Save changes to the client configuration, including redirect URIs, token settings, and more.

• Delete: Remove the client entirely from the system, revoking all tokens and ending active sessions.

• Delete Bearer Tokens: Invalidates the bearer tokens issued for this client, requiring re-authentication.

6. Security and Audit Logs

For each client, R-Auth logs actions such as:

• Client Creation/Deletion: Tracks when a client is registered or removed.

• Token Issuance/Revocation: Logs when tokens are issued or revoked, providing insight into session activity.

• Redirect URIs Changes: Logs any updates to critical URIs to ensure compliance and prevent misconfigurations.