• Type: Sub-Task
    • Status: Closed
    • Priority: Minor
    • Resolution: Completed
    • Affects Version/s: None
    • Fix Version/s: 1.0-portal_7.1.0
    • Component/s: None
    • Labels:


      Portlet: OAuth2 Consent / Authorization Portlet

      Use-Case: REQ001.UC001 Obtain tokens using Authorization Code Grant


      From Product Definition document (amended):


      When the Portal has received a valid request from an Application requesting authorization, the Portal User should be presented with an Authorization Interface.


      The goal of the Authorization Interface is to provide Portal Users with the ability to Allow or Deny an Application’s request while providing the User with everything they need to make an informed decision about doing so.


      The Authorization Interface should include the following components:

      • Portal Website Name/Logo – The User should recognize the Portal that they’re authorizing the Application to have access. The Authorization Interface should have the same theme applied as the rest of the Portal, including any identifying logos and website names.
      • User Identification – If the User is already logged in with the Portal, they should be able to confirm the Portal User they’re logged in as. Their name and Photo should be displayed in the top corner of the screen, similar to how it would be presented elsewhere in the Portal.
      • Authentication Details – In addition to being able to identify the Portal, the User should be able to identify the Web Server Application that brought them there. This is where the name, description, and icon that were collected during Client Registration (REQ011.UC001 Register/Create OAuth2 Application) should be used.
      • Requested Scope – The Interface should display all scopes that the Remote Application is requesting. These should be short, human-readable, strings that clearly state to the Application User what the Application would be able to do. If the Portal also collects a list of scopes that the Application will not be granted, these may also be listed here. By providing Application Users with a clear disambiguation of what the Application can or cannot do when given the request scopes, they are able to make a better informed decision.


          Issue Links



              tomas.polesovsky Tomáš Polešovský
              Participants of an Issue:
              0 Vote for this issue
              0 Start watching this issue




                  Version Package