Difference between revisions of "User Consent"
|Line 6:||Line 6:|
In this wiki it is assumed that there can exist only one active
In this wiki it is assumed that there can exist only one active among three parties on the internet, the [[Subject]] (aka [[User]]) the [[Identifier or Attribute Provider]] and the [[Relying Party]]. It is unclear if [[User Consent]] has any specific meaning between the [[Subject]] and the [[Identifier or Attribute Provider]]; that is left for further developments.
Revision as of 11:02, 29 July 2018
Full Title or Meme
- During an authorization request by a Relying Party, the Identifier or Attribute Provider requires user consent redirecting the user to the consent page.
- Consent is used to allow an end user to grant a client access to resources (identity or API).
In this wiki it is assumed that there can exist only one active User Consent among three parties on the internet, the Subject (aka User) the Identifier or Attribute Provider and the Relying Party. It is unclear if User Consent has any specific meaning between the Subject and the Identifier or Attribute Provider; that is left for further developments.
In order for the user to grant consent, a consent page must be provided by the hosting application. The quickstart UI has a basic implementation of a consent page.
- A consent page normally renders the display name of the current user, the display name of the client requesting access, the logo of the client, a link for more information about the client, and the list of resources the client is requesting access to. It’s also common to allow the user to indicate that their consent should be “remembered” so they are not prompted again in the future for the same client.
- Once the user has provided consent, the consent page must inform IdentityServer of the consent, and then the browser must be redirected back to the authorization endpoint.