1. Home
  2. Portal
  3. RE: Registering OAuth 2.0 apps by users

RE: Registering OAuth 2.0 apps by users

Jan Tošovský, modified 5 Years ago.
Registering OAuth 2.0 apps by users
Liferay Master Posts: 576 Join Date: 7/22/10 Recent Posts
We provide some regularly updated content to our users and we would like to offer REST API for it. We expected to authenticate users by their generated tokens, but only Basic and OAuth 2.0 are available in LR at the moment so we've chosen OAuth 2.0 approach, especially Client Credentials flow.
In this case every user needs to register their app to get unique Client ID and Client Secret, used for generating access token.
https://portal.liferay.dev/docs/7-2/deploy/-/knowledge_base/d/oauth-2-0#creating-an-application
But as I understand, in the current LR implementation creating new app is intended for portal administrator as the OAuth 2.0 Administration in Control Panel lists all registered apps, not only those created by logged in user (if access in CP panel permissions are given to him).
So if somebody needs an access our REST API, he have to contact us, we will create App for him and return Client ID and Client Secret back?
Or am I missing something?
thumbnail
David H Nebinger, modified 5 Years ago.
RE: Registering OAuth 2.0 apps by users
Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
Client credentials (nor any of the other OAuth 2 flows) are intended for individual user registration.

Client credentials specifically has a user to impersonate; the credentials provide access to that impersonated user.

Remember that OAuth 2 is authorization only, not authentication. You cannot assume that anyone giving you the token is whomever it was given out to; if someone leaks their client id and secret (quite common for SPA applications, for example), anyone bearing that token will be able to impersonate the user.
Jan Tošovský, modified 5 Years ago.
RE: Registering OAuth 2.0 apps by users
Liferay Master Posts: 576 Join Date: 7/22/10 Recent Posts
Our goal is to give users read-only access to some general (not user related) stuff. Such possibility is offered by e.g. Linked In API https://docs.microsoft.com/en-us/linkedin/learning/getting-started/request-access (here users can get Client ID and Secret in Admin section). In GitHub I can create OAuth2.0 app directly via account settings https://github.com/settings/applications/new. These are examples where users can create apps themselves and they can anytime revoke access tokens if leak is detected.
So it seems to be too restrictive if LR allows to create apps just to portal admins (who see all the registered apps).
thumbnail
David H Nebinger, modified 5 Years ago.
RE: Registering OAuth 2.0 apps by users
Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
Well no, I don't necessarily agree.

They're not user-specific accounts, this would be a single registered application w/ read-only scope on some APIs. Create a secured Liferay user which has necessary permissions for those things they should be able to access, then set that user as the "impersonation" client credentials.

This way your app gives access to what it needs, does not assume authentication of user, only authorization, and will not leak or expose data that you don't want the system to expose.
Jan Tošovský, modified 5 Years ago.
RE: Registering OAuth 2.0 apps by users
Liferay Master Posts: 576 Join Date: 7/22/10 Recent Posts
I understand Client Credentials flow this way: Company creates app (rest client), registers it,  specifies the user used for impersonation, gets Client ID and Secret and use this for generating  token (expiring) for accessing API.
Every company creates its own app, so one impersonated user per app (company).
https://www.oauth.com/oauth2-servers/client-registration/registering-new-application/
If I created a special OAuth App Creator role and assign it to selected API consumers (one per company) so they could access CP/OAuth Creating New App interface, they would see each others Apps with ability to modify them.
So basically I think I understand how things should work, but I am unsure if current LR implementation is correct as it doesn't allow me to utilize it for a typical Client Credentials flow.
thumbnail
David H Nebinger, modified 5 Years ago.
RE: Registering OAuth 2.0 apps by users
Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
Jan Tošovský:

I understand Client Credentials flow this way: Company creates app (rest client), registers it, specifies the user used for impersonation, gets Client ID and Secret and [the app] uses this for generating token (expiring) for accessing API.

Yep, this is how it works on Liferay too.

Every company creates its own app, so one impersonated user per app (company).

This is not a requirement of OAuth2. Best practice is probably to use a separate impersonated user per app, this allows you to be explicit on permissions this user has within the environment, but technically you could use the same impersonated user for all of the registered apps.

If I created a special OAuth App Creator role and assign it to selected API consumers (one per company) so they could access CP/OAuth Creating New App interface, they would see each others Apps with ability to modify them.

Nor is this a requirement of OAuth2. Since Liferay allows for multiple instances (companies), this concept of 'company' does not equal the same out outlined in the link you posted.

So basically I think I understand how things should work, but I am unsure if current LR implementation is correct as it doesn't allow me to utilize it for a typical Client Credentials flow.

It does allow for a typical client credentials flow, it just does not allow your individual instance (company) admins to create or maintain OAuth2 applications individually.