Consents
Last updated
Last updated
Depending on the type of control, scope or legal, consent is slightly different.
Scope consents are given by an account to a client. They indicate that the client can obtain the scope on the account's behalf, and hence act on their behalf. A scope consent is often required but scopes can also be configured to not require consent. A scope consent is always given to a specific account. For example, when you access the Admin UI it will act on your behalf.
Legal consents are given by an account to a tenant. They indicate the account is accepting the statements related to the control, which could be for example service Terms & Conditions. This consent is generally required for an account in order to get enabled.
All consents are persisted in the platform, meaning that when an account consents they'll not need to re-consent in a subsequent request. An account could always decide to remove their consent so next time it will be requested again. It's also possible to persist a rejection, meaning that this would also not be asked again in a subsequent request.
Your applications will need to be able to cope with tokens with limited scopes as accounts could not grant consent. It's your decision when to consider the scope too limited in order to provide your service, though this enforcement is done on your end. As you need to also always validate any token received this should come naturally.