Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
How to protect with Oauth2 a React portlet consuming a Jax-RS rest api?
Hello there, we have a setup where Liferay (7.2) is working as SP in SSO SAML with a third-party IDP, and LR is hosting both the front-end and back-end of an application composed of a React as FE consuming a Rest Jax-RS BE api endpoints.So far everything is working, only our Rest api is freely accessible from the outside world.Our issue now is how to protect the endpoint using OAuth2? The different profiles proposed by OAuth2 in LR seems to not address the need here. The main profile, the Client Credentials approach implies that the FE contains the application secret, which is something we don't want.
The other profile, the Authorization Code profile implies that the user consents to the application, which is something we do not want as well. Because our LR portal is an intranet where all the users are pre-configured to use the apps inside the portal, and there is no need for an extra screen where the users have to consent.The rest of the profiles seems also not practical, either they need the client secret in the React app, or have some other limitation.My question is how to protect our API via Oauth2, while allowing our React front-end to consume it, plus the fact that our users are authenticated through external SSO.Thanks in advance to our experts here.
The other profile, the Authorization Code profile implies that the user consents to the application, which is something we do not want as well. Because our LR portal is an intranet where all the users are pre-configured to use the apps inside the portal, and there is no need for an extra screen where the users have to consent.The rest of the profiles seems also not practical, either they need the client secret in the React app, or have some other limitation.My question is how to protect our API via Oauth2, while allowing our React front-end to consume it, plus the fact that our users are authenticated through external SSO.Thanks in advance to our experts here.
The intent of oauth 2 is to grant authorization to do something.
When you use client credentials, you're giving out the secret for a user that inherently authorizes the use of the api, since, well, you're the one creating the client credentials flow. When you have multiple APIs you host, the client credentials represent the authorization to use a subset of all APIs. The implication though is that the auth granted to the client credentials allows any holder of the secret access to the API, not just your application, so loss of the secret is no big deal. It's like setting up client creds so you can access Liferay public web content; if the secret got away from your app, it's no big deal because you only authorized access to Liferay's public web content.
With auth flow (with or without pkce) allows the user to decide whether they want some app they're using to be able to do things on their behalf. Like if I want to have my notebook app backup my notes on my gdrive, Google has to ask me if I authorize the app to do that. It allows me to confirm that using gdrive is fine, but if it also wanted to access my email, well then maybe I need to rethink using the app. So the user is authorizing the app to invoke the service in the provider, not the provider authorizing the app to invoke the service.
Your case doesn't sound like either of these, which tells me that you don't really need oauth2 at all. Sure, you likely need to protect them using SSO, but neither of these other cases apply so oauth2 is not needed.
When you use client credentials, you're giving out the secret for a user that inherently authorizes the use of the api, since, well, you're the one creating the client credentials flow. When you have multiple APIs you host, the client credentials represent the authorization to use a subset of all APIs. The implication though is that the auth granted to the client credentials allows any holder of the secret access to the API, not just your application, so loss of the secret is no big deal. It's like setting up client creds so you can access Liferay public web content; if the secret got away from your app, it's no big deal because you only authorized access to Liferay's public web content.
With auth flow (with or without pkce) allows the user to decide whether they want some app they're using to be able to do things on their behalf. Like if I want to have my notebook app backup my notes on my gdrive, Google has to ask me if I authorize the app to do that. It allows me to confirm that using gdrive is fine, but if it also wanted to access my email, well then maybe I need to rethink using the app. So the user is authorizing the app to invoke the service in the provider, not the provider authorizing the app to invoke the service.
Your case doesn't sound like either of these, which tells me that you don't really need oauth2 at all. Sure, you likely need to protect them using SSO, but neither of these other cases apply so oauth2 is not needed.
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™