Type: Feature Request
Affects Version/s: None
Fix Version/s: None
Component/s: Application Security > OAuth2
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.
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)
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.
Currently, as far as I understand, we have two entities:
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