Client registration

In order to act as a Client an application has to be registered with the OAuth Server. Registration can be initiated by filling out the respective form on the IDSC site.

Data provided by Client

Client type

The Client must be classified as one of the following types:

INTERNAL (IONOS application, e.g. webproportal.ionos.com)
PARTNER (Partner application, e.g. hidrive.com)
EXTERNAL (Not connected to IONOS, e.g. google.com)

Trust level

Each Client must specify its trust level according to the OAuth definition.

PUBLIC (e.g. pure JavaScript application)
CONFIDENTIAL (e.g. web application running on a server)

Default scopes

INTERNAL and PARTNER type Clients will not be able to specify the scopes at runtime. The desired scopes have to be negotiated beforehand and are hard wired as default scopes to the Client.

Redirect URIs

The Client must register one or more redirect URIs which will be used to redirect the authenticated user to during the Authorization Code flow. URLs can be maintained by the client using our IDSC tool.

In most cases the Client will be a web application, where the redirect URI must use a https:// scheme, e.g. https://webapp.example.com/oauth. Mobile apps might use other kinds of URIs like com.example.mobile.app.android://oauth.

Display name

The Client must supply a short descriptive application name to be presented on OAuth consent pages.

PKCE support

The Client must tell whether Proof Key for Code Exchange by OAuth Public Clients is supported.

Token lifetime

The Client may determine the access token and refresh token lifetimes to be used within the OAuth Server. The refresh token lifetime is actually the session lifetime. A refresh token lifetime of 0 suppresses refresh token delivery entirely.

Single Log Out

Should the client be part of the IONOS SingleLogOut environment? Do Users expect their access tokens to be revoked when logging out from ControlPanel, for example?

Addressee for Client secret

In case of CONFIDENTIAL Clients a secret will be generated for authentication. An email address with GPG public key must be provided for the secret to be sent to.

Mandator check

The id application is reachable by dedicated market domains (id.ionos.de, id.ionos.co.uk, etc.). Should the application perform a check for the matching site upon user login, or is the Client entirely mandator agnostic?

RFC 9068 Access Tokens

By default access tokens will be opaque ones: short random strings without special meaning. Clients may opt to get RFC 9068 compliant JWTs instead. These contain basic OAuth session information and are significally larger in size. Some resource servers prefer these tokens, because they may save /introspect calls in certain situations. Be aware of possible size limitations in HTTP headers or cookies. For signature validation instructions see OpenID Connect.

Data provided by OAuth Server

Client ID

The OAuth Server supplies a unique client ID, e.g. webapp.example.com. By obligatory convention, test clients within the production system must conform to the pattern playground.*, for example playground.webapp.example.com.

Client secret

The OAuth Server supplies a unique initial password for Basic Authentication during the OAuth token flow. This should be changed soon on the IDSC site.