Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-124384

Persisting OAuth2 grants separately from authorization codes


    • Type: Feature Request
    • Status: Closed
    • Priority: Minor
    • Resolution: Implemented in Platform
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:



      Currently behaviour:

      When Liferay as an authorization server receives an authorization request, the user will always be prompted before providing an authorization code to the client application.

      Problem statement:

      There are two kinds of OAuth2 Clients:

      • Confidential clients (an application able to keep a secret, most of the time, it's living inside of a server)
      • Non-confidential clients (an application unable to hide secrets, eg. a javascript application running inside of a browser, a mobile native application)

      Liferay as an authentication server provides a refresh_token alongside the access_token.

      This is perfectly fine for confidential clients that are able to securely store that refresh_token.

      With a mobile native application, this is still manageable: one technique is to store the refresh_token in the secure store protected by the device's strong authentication.

      Now, for the client running inside of the user agent, this is more difficult. Some developers are tempted to store oauth2 tokens inside the browser's SessionStorage but it is risky: any script running on the site could access it.

      The current best practice is rather to rely on short lived access_token and have the authorization code flow run again with prompt=none in the authorization request and deal with possible exceptions.

      Most of the time, the Resource owner's session at the Authorization Server should still be alive, and it would be the case in the current Liferay state.

      However, prompt=none is currently not possible with Liferay as Liferay will request the Resource owner's consent for each authorization request.

      Proposed design:

      Currently, as far as I understand, we have two entities:

       - OAuth2Authorization

       - OAuth2ScopeGrant

      The first is linked to a list of grants (the second) and is bound to the authorization request.

      Other OAuth2 middlewares manage consents separately from authorizations.

      My proposition would be to have a third entity that would track all consents that have been granted by a user.

      This way, when Liferay receives an authorization request:

       - For each already granted consent, don't ask again

       - For each not alreay granted consent, ask and remember

      As a consequence, that would also allow us to offer a prompt=none option where:

       - Automatic redirection is triggered if resource owner has a session and has already granted every requested scope

       - Error returned otherwise



          Issue Links



              support-lep@liferay.com SE Support
              fabian.bouche Fabian Bouché
              0 Vote for this issue
              2 Start watching this issue




                  Version Package