Configuration Attributes

1. CallBack URL:

• A callback URL in OAuth (Open authorisation) is a particular URL provided by the client application during the OAuth authorisation process. It is also referred to as a redirect URL or callback URI. The authorization server sends the user back to this callback URL along with a code for authorization or an access token once the user authorizes the client application permission to access their protected resources.

• The authorization server can connect with the client application to convey the results of the authorization using the callback URL. By obtaining the authorization code or access token from the URL parameters, it enables the client application to carry on with the process of authentication. When beginning the OAuth process, the client application includes the callback URL in its authorisation request. When the user approves the request, the authorization server generates the authorization code or access token and sends the user's browser back to the callback URL, delivering the necessary permission data along the way.

• The callback URL's arguments must be parsed and validated by the client application in order to confirm the validity of the request. The client application can then utilize the authorization code or access token acquired from the callback URL to submit authorized API requests on behalf of the user.

• It's important to remember that during the initial setup of the application, the callback URL must be submitted to the authorization server. By doing this, the redirection is confirmed to be legitimate and unauthorized redirects to arbitrary URLs are avoided.

2. App Name:

• The name or title supplied to an OAuth application during configuration is referred to as the "App Name" in this context. You normally include information about your application when you establish an OAuth application, including its name, description, website URL, and other relevant information. The term "App Name" explicitly refers to the name you select for your application's identification.

• When requesting permission or authorizing access to their protected resources, users may quickly recognise and identify your application thanks to the App Name, which is frequently used for display reasons. During the OAuth flow, it could be shown via user consent screens, permission questions, or other user-facing interfaces.

• Depending on the OAuth provider or platform you are using, there may be a difference in the specific location where you provide the App Name. However, it is usually part of the application registration or configuration form, where you set up your OAuth credentials.

• You may improve the user experience and support building trust between your application and its users by offering a distinct and recognisable App Name.

3. Client ID:

• The client ID is a distinctive identity given to a client application during a registration process with the OAuth provider in OAuth (Open Authorization). One of the credentials that the client application uses to log in to the authorization server is this one.

• Typically, you must register any OAuth applications you generate with the OAuth service or provider you want to use. The supplier gives your application a client ID during this registration. A string or alphanumeric value known as the client ID acts as a special identification for your application.

• An essential piece of data needed in the OAuth flow is the client ID. The client application includes the client ID as part of the authorisation request to the authorization server when starting the OAuth process. The authorization server can now recognise the client application submitting the request thanks to this.

• The client ID is used to confirm the legitimacy of the client application, together with additional credentials such as a client secret (in certain flows). It makes sure that only reputable client apps can get authorization tokens or gain access to restricted resources, which helps prevent unauthorized access.

• The client ID must be protected and handled with care as sensitive data. Sharing or revealing the client ID might result in security flaws or unauthorized access to your account.

4. Client Secret:

• The client secret in OAuth (Open authorisation) is a confidential credential that a client application uses to identify itself to the authorisation server. Between the client application and the server, it is a distinct string or token that acts as a method of authentication and authorisation.

• Typically, the authorization server generates and provides the client secret during the OAuth application registration process. It should never be revealed to the public or shared; it was meant to be kept secret.

• When sending requests to the authorization server as part of the OAuth flow, the client application also sends the client secret along with the client ID. The client secret enables the client application to build confidence with the server and prove its identity.

• The Authorization Code flow and the Client Credentials flow are two OAuth grant types that frequently employ the client secret. By requiring a secret piece of information that is only known by the client application and the authorization server, it offers an additional layer of protection.

• The client secret must be handled with care, and it must be kept secure from unauthorized access. It's essential to store the client secret securely using encryption or other suitable technologies to avoid security breaches and unauthorized usage.

5. Scope :

• In OAuth (Open Authorization), the scope is a parameter used in the authorization request to specify the permissions or access levels requested by the client application. It defines the specific resources or actions that the client application wants to access on behalf of the user.

• The scope parameter is included in the authorization request sent from the client application to the authorization server. It informs the server about the intended scope of access requested by the client.

• The scope values can vary depending on the specific OAuth implementation or the API being accessed. Examples of common scope values include:

• These are just a few examples, and the actual scope values depend on the API or service being accessed. The OAuth provider or API documentation typically specifies the available scopes and their meanings.

• During the OAuth flow, the user is typically presented with the requested scope(s) and asked to grant or deny permission for the client application to access the requested resources or perform the requested actions. The authorization server may display the scope information to the user as part of the authorization prompt or consent screen.

• By specifying the scope, the client application can ensure that it only requests the necessary permissions required for its intended functionality. This helps protect user privacy and limits access to sensitive resources only when needed.

6. Authorization Endpoint :

• The authorization endpoint in the OAuth protocol is a URL that the authorisation server provides. The client application starts the OAuth flow at this endpoint by rerouting the user to request their consent to access protected resources.

• A client application refers the user's browser to the authorization endpoint when it needs to access a user's protected resources. Each OAuth implementation requires a unique authorization endpoint, which is often given by the OAuth provider or authorization server.

• The user is shown an authorization request or consent screen at the authorization endpoint. The user is prompted to approve or deny access on this page, which details what permissions the client application is asking. Whether the client application gets an access token or an authorization code to access the protected resources depends on the user's choice.

• The client application builds the authorisation request by containing several parameters including client ID, redirect URI, scope, and possibly status, among others. The authorization endpoint typically allows HTTP GET queries.

• The authorization server then routes the user's browser back to the redirect URI defined by the client application once the user accepts or rejects authorisation. Depending on the OAuth flow being used, this redirection contains an authorization code or an access token that enables the client application to gain the required credentials to access the protected resources.

• The individual OAuth implementation or service being used determines the URL of the authorisation endpoint and the parameters it expects. The essential information for creating the permission request and interacting with the authorization endpoint is normally provided by the OAuth provider or service documentation.

7. Token Endpoint :

• The token endpoint in the OAuth protocol is a URL that the authorization server provides. It is the point where the client application trades an access token for an authorisation code or other credentials.

• The client application requests an access token from the token endpoint after receiving an authorization code from the authorisation endpoint. The client application must be verified as legitimate before the authorization code and access token may be exchanged at the token endpoint.

• The authorization code, client ID, client secret (in some flows), redirect URI, and grant type are common request payloads that the client application generally includes in a POST request to the token endpoint.

• The OAuth grant type being utilized, such as the authorization code grant, client credentials grant, or implicit grant, is indicated by the grant type argument.

• The token endpoint checks the specified credentials and the validity of the authorization code after receiving the request. The token endpoint produces and returns an access token to the client application if everything is legitimate.

• When performing API calls to access the user's protected resources, the client application can utilise the access token as a credential to authenticate itself. Depending on the OAuth flow and setup, the token endpoint could additionally include further details like an expiration date or a refresh token.

• The exchange of credentials for access tokens is made possible via the token endpoint, which is essential to the OAuth flow. Depending on the OAuth implementation or service being utilized, the token endpoint will have a specific URL and set of parameters. The essential information for connecting with the token endpoint and getting access tokens is often available in the OAuth provider or service documentation.

8. User Info Endpoint :

• The authorization server or a related user information service may offer the user info endpoint in OAuth, which is optional. It enables the client application to get more details about the verified user.

• After receiving an access token, a client application can use the user info endpoint to send a request and get the user's profile data or other pertinent information. Without requiring direct access to the user's credentials, this endpoint offers a standardized method for client applications to retrieve user-specific information.

• The access token must be sent with the request as a query parameter or authorization header for the user info endpoint to allow HTTP GET queries. The OAuth implementation or service being used determines the exact URL and parameters the user info endpoint expects.

• The client application can get data such as the user's name, email address, profile image, or any other information authorized by the user by gaining access to the user info endpoint. Depending on the implementation, the data delivered by the user info endpoint may be in a variety of forms, such as JSON or XML.

• It's vital to remember that depending on the OAuth provider or service, the availability and structure of user information from the user info endpoint may change. Although it is not a basic component of the OAuth protocol, the user info endpoint is frequently used as an addition to OAuth to offer standardized user data access.

• The client application must confirm that it has been given the appropriate rights to access the user's information before utilizing the user info endpoint, often using the scope parameter during the first authorization request.

9. Client Credentials - Header/Body :

• In the OAuth protocol, "InHeader" and "InBody" refer to the methods used to include the client credentials (such as client ID and client secret) in the OAuth request.

• InHeader: In this method, the client credentials are included in the HTTP request header. Specifically, they are typically included in the "Authorization" header field using the "Basic" authentication scheme. The client ID and client secret are concatenated with a colon (:) and then Base64 encoded before being included in the header.

• InBody: In this method, the client credentials are included as parameters in the request body of the OAuth request. The client ID and client secret are sent as form-encoded or URL-encoded parameters.

• The choice between using "InHeader" or "InBody" to include the client credentials depends on the specific OAuth implementation and the security requirements of the system.

• The "InHeader" method is commonly used and considered more secure because it avoids exposing the client credentials in the request body, which may be logged or visible in certain scenarios. It also aligns with the usage of HTTP authentication schemes.

• The "InBody" method is used in cases where it might be more convenient or necessary to include the client credentials as parameters in the request body, especially when interacting with OAuth servers that don't support the "InHeader" method.

• It's important to note that the use of client secrets in OAuth flows depends on the specific grant type and the requirements of the authorization server. Not all OAuth flows require or support client secrets. For example, in public clients, such as mobile or JavaScript applications, client secrets are often not used, and alternative flows are employed for authentication.