OIDC Details and Parameters
Use this reference to see all possible parameters used in the different OIDC flows.
Well Known Information
Most options and endpoints of your Unidy instance can be found under the well know discovery URL. You can access it via https://<TENANT>.unidy.de/.well-known/openid-configuration . Take a look at the example from our demo instance: https://demo.unidy.de/.well-known/openid-configuration.
Authorization
Most OIDC flows start at the authorization endpoint that can be found under https://<TENANT>.unidy.de/oauth/authorize and accepts several parameters. The most important part of the OIDC flow is the use of the response_type as it defines what you will receive at the end of the flow.
See the list of parameters:
Parameter | Description |
response_type | This defines the result that is returned at the end of OIDC flow.
id_token will return an ID token (see link).
code will return an authorization code that can be exchanged for an access token (see link).
token will directly return an access token (see link).
They can also be combined to receive multiple results like response_type=id_token code . |
client_id | Unidy configures possible scopes and redirect URLs in so called OAuth clients. Each connected system will have a different client and therefore a different client_id (e.g. for shop and mobile app). You will be provided with the values by the Unidy team. |
redirect_uri | This is the URI where the user is redirected after logging in. All possible URIs need to be configured inside the Unidy instance. It is possible to use wildcards for registering possible redirect URIs. That can be useful e.g. for shop cases where you need to redirect dynamically. In that case. the registration could look like https://www.myshop.com/products/* . |
scope | This defines what data of the user can be accessed. The user will see the requested permission in the consent screen after login in. When requesting an ID Token the scope needs to be at least openid , but can also contain additional fields. What fields are available depends on the configuration of the OAuth client in the Unidy backend. You can see most scopes in your well known discovery URL (example) but more can be added depending on your custom Unidy setup. |
prompt | When omitted, the default value login is used which indicates, that the user will be presented a login screen. The other option is none and only used when using the link. |
state | The same value passed via state is returned to you at the end of the flow. With that you can make sure, that you really initiated the flow and could use it to resume the users session. Since it is visible in the browser history it must not contain any sensible information. |
response_mode | Defines, how the response is returned to you. When omitted the default value fragment is used and the data is added to the response URL as fragments. When set to form_post the |
login_hint | You can pass this parameter to prefill the email in the users login form. E.g. login_hint=john@doe.com |
Scopes
You can see most scopes in your well known discovery URL (example).
See scopes to access infos about the user:
Scope | Fields | Description |
openid | sub | Unidy ID that should be used to identify the user. |
profile | given_name family_name name gender updated_at birthdate | |
email | email | |
email_verified | email_verified | indicates if the user has verified his email account and is thereby activated. |
phone | phone | |
address | formatted street_address locality region country postal_code address_line_1 address_line_2 street house_number country_code company |
See scopes for API usage:
Scope |
admin:read |
admin:write |
subscriptions:read |
subscriptions:write |
subscriptions_batch:write |
custom_attributes:read |
custom_attributes:write |
users:read |
users:read_by_email |
users:change_email |
users:write |
newsletter_subscriptions:write |
newsletter_subscriptions:read |
tickets:read |
tickets:write |
tickets_batch:write |
Additional fields and scopes can individually be configured on your instance and then be requested.