Registering OAuth 2.0 apps by usersRegistering OAuth 2.0 apps by usershttps://liferay.dev/en/c/message_boards/find_thread?p_l_id=119785333&threadId=1179307792024-03-29T11:49:08Z2024-03-29T11:49:08ZRE: Registering OAuth 2.0 apps by usersDavid H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1179510342019-12-02T22:11:07Z2019-12-02T22:11:07Z<div class="quote-title">Jan Tošovský:</div><blockquote><br />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.</blockquote><br />Yep, this is how it works on Liferay too.<br /><br /><blockquote>Every company creates its own app, so one impersonated user per app (company).</blockquote><br />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.<br /><br /><blockquote>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.</blockquote><br />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.<br /><br /><blockquote>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.</blockquote><br />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.David H Nebinger2019-12-02T22:11:07ZRE: Registering OAuth 2.0 apps by usersJan Tošovskýhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1179501602019-12-02T17:02:37Z2019-12-02T17:02:37ZI 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.<br />Every company creates its own app, so one impersonated user per app (company).<br /><a href="https://www.oauth.com/oauth2-servers/client-registration/registering-new-application/">https://www.oauth.com/oauth2-servers/client-registration/registering-new-application/</a><br />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.<br />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.Jan Tošovský2019-12-02T17:02:37ZRE: Registering OAuth 2.0 apps by usersDavid H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1179413682019-12-01T23:11:10Z2019-12-01T23:11:10ZWell no, I don't necessarily agree.<br /><br />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.<br /><br />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.David H Nebinger2019-12-01T23:11:10ZRE: Registering OAuth 2.0 apps by usersJan Tošovskýhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1179388392019-12-01T18:22:53Z2019-12-01T18:22:53ZOur 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 <a href="https://docs.microsoft.com/en-us/linkedin/learning/getting-started/request-access">https://docs.microsoft.com/en-us/linkedin/learning/getting-started/request-access</a> (here users can get Client ID and Secret in Admin section). In GitHub <a href="https://github.com/settings/applications/new"> </a>I can create OAuth2.0 app directly via account settings <a href="https://github.com/settings/applications/new">https://github.com/settings/applications/new</a>. These are examples where users can create apps themselves and they can anytime revoke access tokens if leak is detected.<br />So it seems to be too restrictive if LR allows to create apps just to portal admins (who see all the registered apps).Jan Tošovský2019-12-01T18:22:53ZRE: Registering OAuth 2.0 apps by usersDavid H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1179372952019-11-30T07:25:54Z2019-11-30T07:25:54ZClient credentials (nor any of the other OAuth 2 flows) are intended for individual user registration.<br /><br />Client credentials specifically has a user to impersonate; the credentials provide access to that impersonated user.<br /><br />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.David H Nebinger2019-11-30T07:25:54ZRegistering OAuth 2.0 apps by usersJan Tošovskýhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1179307782019-11-29T17:58:54Z2019-11-29T17:58:54ZWe 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.<br />In this case every user needs to register their app to get unique Client ID and Client Secret, used for generating access token.<br /><a href="https://portal.liferay.dev/docs/7-2/deploy/-/knowledge_base/d/oauth-2-0#creating">https://portal.liferay.dev/docs/7-2/deploy/-/knowledge_base/d/oauth-2-0#creating</a>-an-application<br />But as I understand, in the current LR implementation creating new app is intended for portal administrator as the OAuth 2.0 Adm