• OAuth2 Server Configurations
  • Grant Types
    • Authorization Code Grant
    • Password Grant
    • Implicit Grant
    • Refresh Token Grant
    • Client Credentials Grant
  • Security Options
    • PKCE Verification
    • Authorize Scopes
  • Access Token
    • Token Type
  • TTL
    • Auth Token TTL
    • Access Token TTL
    • Refresh Token TTL

#OAuth2 Server Configurations

With SSOfy, you have complete control over the OAuth2 server configurations and the way tokens should be generated.

#Grant Types

A number of methods known as grant types are used in OAuth 2.0 to obtain an access token, a type of authorization credential that enables a client application to access protected resources on behalf of a resource owner (user).

#Authorization Code Grant

This is the most common type of grant. It entails exchanging an authorization code for a token of access. By redirecting the resource owner to the authorization endpoint of the authorization server (SSOfied Login Page), the client first obtains an authorization code from the authorization server. The client then makes a request, along with the authorization code, to the authorization server's token endpoint to obtain an access token.

#Password Grant

a.k.a. Resource Owner Password Credentials Grant, This grant type lets a client receive an access token directly from the authorization server by giving the login and password.

#Implicit Grant

This grant is similar to the authorisation code grant, except that the client obtains the access token without first getting an authorisation code. This is common in client-side programs like JavaScript web applications.

#Refresh Token Grant

This grant type is used to get a new access token by providing a refresh token to the authorization server. The refresh token is a long-lived credential that is issued along with the access token and can be used to receive a new access token when the original access token expires.

#Client Credentials Grant

Clients utilize this grant type to obtain an access token based on client credentials without involving the user. This is primarily used for server-to-server communication.

#Security Options

#PKCE Verification

Enable or Disable the PKCE verification function.

PKCE stands for "Proof Key for Code Exchange" and used to secure the authorization flow between a client application and authorization server (SSOfy).

The purpose of PKCE is to prevent authorization code interception attacks, which occur when an attacker intercepts the authorization code returned by the authorization server and uses it to obtain an access token. PKCE helps to mitigate this risk by adding a layer of security to the authorization flow.

#Authorize Scopes

The user will be forwarded to the Authorization page following a successful login. They can choose to accept or deny the request after reviewing the list of permissions that the client application requests access to.

By default, this functionality is enabled, but if you turn it off, all permissions will be granted automatically and the authorization page will be skipped.

#Access Token

#Token Type

SSOfy supports a wide variety of token generation algorithms. The JWT's HSxxx family of tokens (HS256, HS384, and HS512) are the simplest forms of tokens because all that is needed is a passphrase which you submit to SSOfy as well as your backend.

From the dropdown you can choose between API Token (default) and JWT - HSxxx tokens.

The API Token is generated and managed by SSOfy. Unlike JWT tokens, they do not carry any data within their payload. You will be completely reliant on the SSOfy API for Token Verifications. This is an ideal choice when you want short tokens with no data to be extracted by strangers.

With "JWT" on the other hand, if you require more secure tokens, you should first generate a key on the JWT Keys page. Then, your keys will show up and be selectable in the dropdown.

#TTL

#Auth Token TTL

Length of time that an Authentication Token is considered valid and can be used to exchange for an Access Token. Once the TTL has expired, a new token must be obtained.

#Access Token TTL

The amount of time that an Access Token is valid and can be used to access protected resources. The SSO server issues an access token to the client after the client has been successfully authenticated and authorized. The access token serves as a proof of the authorization and the client can use it to access protected resources without having to repeatedly send credentials to the server. The Access Token TTL determines the lifespan of the access token, after which it becomes invalid and the client has to request a new one using the Refresh Token.

#Refresh Token TTL

It is the amount of time that a refresh token remains valid after being issued. The refresh token is used to obtain a new access token when the original access token expires.

A low Refresh Token TTL value can increase security, but it can also make the user experience less convenient.

A high Refresh Token TTL value can reduce the frequency of token refresh requests and make the user experience more convenient, but it can also reduce security by extending the time window in which a stolen refresh token can be used.

The optimal Refresh Token TTL value will depend on the specific use case and security requirements of the application.