7

I've been going through some documents regarding OAuth2 confidential and non-confidential authorisation flows, namely this and the RFC.

From my understanding, the non-confidential flow does not require the client_secret, or better yet, you actually shouldn't use the client_secret because you're assuming anyone can get a hold of it along with the client_id, thus making it easier to pose as the client app.

So in order to implement the non-confidential flow, the client must first work with the client_id issued by the server and a state generated by the client. Then the client should make use of a code returned by the server and the same state value. A redirect_uri must also be registered with the server.

AFAIK (As far as I know) that's what distinguishes the confidential from the non-confidential flow: the confidential flow requires the client_secret whereas the non-confidential doesn't. Moreover, this is what defines the non-confidential flow, the lack of a client_secret. Am I correct in assuming this?

Section 2.3 doesn't seem to be specific regarding this.

Related Q, from Section 4.1.3:

If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.

What exactly sits under "other authentication requirements"? Isn't this any client that has to be authorised?

Community
  • 1
takecare
  • 171
  • 4
  • 1
    Should've added that the non confidential and confidential also differ in the sense that you can't refresh tokens with a non confidential client. – takecare Jan 17 '18 at 16:41

3 Answers3

1

A confidential client can keep/protect secrets, whereas a non-confidential client cannot.

Because non-confidential clients cannot keep secrets, the OAuth 2 specification does not allow Refresh tokens, or any kind of confidential information to be shared with such clients. This also means non-confidential clients cannot be trusted with secret or private keys.

Without such keys a client cannot authenticate itself (i.e. securely identify itself with a given client_id) with the authorization server.

Even though a non-confidential client is assigned a client_id, anyone can masquerade as that client_id. As such the authorization server deliberately limits the kind of information it will share with a non-confidential client.

HTLee
  • 1,772
  • 15
  • 30
1

AFAIK (As far as I know) that's what distinguishes the confidential from the non-confidential flow: the confidential flow requires the client_secret whereas the non-confidential doesn't.

Rather than the flow itself, it's the client that distinguishes confidential from non-confidential (I've seen it more commonly referred to as public.)

Confidential clients are those that have the capability to store secrets. Traditional web applications with a backend server fall into this category. As secrets can be stored OAuth flows can use a client_secret in the authorization flow.

A public client (non-confidential client) is an application that is not capable of keeping a client password confidential. Implementing of client_secrets is not used as it can't be trusted as secure.

What exactly sits under "other authentication requirements"? Isn't this any client that has to be authorised?

I think there may be some fringe case where instead of client credentials, the resource owner has a different way of implementing client credentials. In most cases, I don't think you have to worry about this.

Kyle Fennell
  • 921
  • 4
  • 12
0

"other authentication requirements" is probably referring to the authentication methods, other than client credentials (client id and client secret). For example, client authentication (with certificates).

Mike
  • 146
  • 2