Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
en:2.0:single_sign_on [2026/09/11 09:16] – [B. Configuring an App (Relying Party) to use SSO with Admidio] kainhoferen:2.0:single_sign_on [2026/09/11 09:29] (current) – [C. Configuring Admidio with the Relying Party] kainhofer
Line 382: Line 382:
   * **Client ID** (unique identifier of the client): typically the URL of the OpenID client (RP)((Some RPs use basic auth by default, which does not allow special characters in the username. In this case, the URL MUST NOT be used, as this will prevent successful login! Other OpenID clients hardcode the client ID as their URL.))   * **Client ID** (unique identifier of the client): typically the URL of the OpenID client (RP)((Some RPs use basic auth by default, which does not allow special characters in the username. In this case, the URL MUST NOT be used, as this will prevent successful login! Other OpenID clients hardcode the client ID as their URL.))
   * **Client Secret** (basically the client's password to access Admidio): Admidio will create this secret when the RP is created and will store it only as a hash in the database. Make sure to copy the secret before saving, as it is not possible to retrieve it later! One can, however, simply recreate a new secret and paste that into the RP's configuration.   * **Client Secret** (basically the client's password to access Admidio): Admidio will create this secret when the RP is created and will store it only as a hash in the database. Make sure to copy the secret before saving, as it is not possible to retrieve it later! One can, however, simply recreate a new secret and paste that into the RP's configuration.
-  * **Redirect URI** (where the user is redirected after successful login)+  * **Redirect URI** (where the user is redirected after successful login). Many clients send an explicit URL where users are returned after a successful OIDC logout. To prevent security issues, only explicitly listed URLs are allowed. Multiple URLs can be given, one per line, and a **%%*%%** can be used as a placeholder (not allowed in the protocol or the domain name, only in the path after the domain). Some clients (like Wordpress) append variable options like the user's language. In that case, the placeholder should be used.
  
-  * **User ID field**: Whether the client gets the numeric Admidio user id, the globally unique UUID, or the user's login name as user ID+  * **User ID field**: Whether the client gets the numeric Admidio user id, the globally unique UUID, or the user's login name as user ID to uniquely identify users. This is not the suggested login name in the client, but an internal identifier.
   * **Permitted scopes**: OpenID defines certain groups of profile data, for which permission can be granted. The RP will include the scopes it is interested in in its login request, and the OpenID Provider (OP, Admidio in our case) will return the profile fields ("claims") corresponding to those scopes, if permission is given. The "openid" scope MUST always be present in OpenID!   * **Permitted scopes**: OpenID defines certain groups of profile data, for which permission can be granted. The RP will include the scopes it is interested in in its login request, and the OpenID Provider (OP, Admidio in our case) will return the profile fields ("claims") corresponding to those scopes, if permission is given. The "openid" scope MUST always be present in OpenID!
   * Further **profile data/fields** transmitted to the client on successful login   * Further **profile data/fields** transmitted to the client on successful login
  • en/2.0/single_sign_on.1789111018.txt.gz
  • Last modified: 2026/09/11 09:16
  • by kainhofer