drop explicit requirement/mention of client_ids

[aaronpk]

from Justin:

---

§2.2: While it’s usually the case that the AS issues the client_id, it’s increasingly common in profiles of OAuth 2 for that to no longer be true. Ultimately, the AS needs to be able to :recognize: the client software identified by the client ID, and issuing an ID associated with some known set of policies (like which redirect URIs are allowed) is just one way to do it. We should be more precise in the definition and allow for the more general use cases that we already know are in the wild. Additionally, fixed client IDs are a thing, and so the restriction of it being unique to the AS is also untrue. Now allowing client_id choice is important mostly for registration-based clients, where the AS does issue the ID, and not for other cases where the AS “recognizes” and processes the client ID, like in OIDC’s Federation profile and some other specs.

[tlodderstedt]

uniqueness of the client_id within the AS's namespace is still required, however opening it up to externally managed client ids make sense. We also use such client ids.

[dickhardt]

agreed

[ybelenko]

I've used popular PHP server implementation which sets client ID required for all grants. Maybe my use case is wrong.

Can somebody explain to me whether I should consider internal front web application as API client or not? It feels that way.

I know that "password" grant has been deprecated and shouldn't be used, but what if I want to use it for private API only? I like token system so I don't wanna roll back to cookies and sessions.

To summarize my question, can I use OAuth flow at my front login page? And should I use it without client ID(extend password grant and make client_id optional) or I need to create static one(eg. "website-front").

[tlodderstedt]

To summarize my question, can I use OAuth flow at my front login page? And should I use it without client ID(extend password grant and make client_id optional) or I need to create static one(eg. "website-front").

@ybelenko I'm not sure about your use case. The objective of an OAuth flow is to issue an access token for API access. How does this fit with your front login page?

[ybelenko]

@tlodderstedt Yes, I now that OAuth flow has been designed for API access. Since it's most stable and secure standard of authorization right now I don't want to reinvent the wheel or use cookie sessions which got many drawbacks. Anyway, many articles already describe this case:

From When to use the Password Grant Type | Okta Developer

While a service should never let a third party developer use the Password grant, it is quite reasonable for a service’s own application to ask the user to enter their password. For example, if you download Twitter’s mobile app, you wouldn’t be surprised if the first thing it does when you launch is ask for your Twitter password. In contrast, if you download a third-party Gmail app, it should use Google’s OAuth server rather than ask you to enter your Gmail password.

The benefit of this grant type is that it lets the application take advantage of the rest of the benefits that OAuth provides around access tokens and token lifetimes. Instead of storing the user’s password on the device, the application only has to touch the user’s password for as long as it takes to get the access token, then it can store and use the access token instead.

From Password Grant - OAuth 2.0 Simplified:

A common use for this grant type is to enable password logins for your service’s own apps. Users won’t be surprised to log in to the service’s website or native application using their username and password, but third-party apps should never be allowed to ask the user for their password.

From Resource Owner Password Credentials Grant | PHP OAuth2 Server :

This grant is a great user experience for trusted first party clients both on the web and in native applications.

I consider my own front login page as trusted first party client. Talking about new 2.1 framework version, since password grant is deprecated and not recommended. I don't understand whether it's not recommended entirely or as part of public API? Can I turn it on for trusted apps while I don't describe that flow in public API documentation?

[tlodderstedt]

@ybelenko I think what you are looking for is an internal API for password checks or you just use your OAuth AS as login server via OpenID Connect (code flow)

[ybelenko]

@tlodderstedt I've already implemented password grant for internal API. I'm just a user not an author of this spec, so I cannot understand why password grant has been deprecated and is this a big security vulnerability to still use it for internal API.

As long as I use password grant for internal API I can extend it anyway I want, including make client_id optional. client_id seems not really important/valuable for first party trusted apps.

[aaronpk]

This was updated in #123