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?

  • 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

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.


"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).

  • Could be.. but the RFC seems a bit vague here. If you could back this up with more specific / more explicit information, that would be great. – S.L. Barth Aug 1 '18 at 15:16
  • tools.ietf.org/html/rfc7523 is an example with jwt tokens. – Geir Emblemsvag Dec 29 '18 at 18:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.