Return to Question

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?

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?

I've been going through some docs 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 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 to assume 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 does exactly fit in "other authentication requirements"? Isn't this any client that has to be auth'ed?

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?

I've been going through some docs 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, the same state value. A redirect_uri must also be registered with the server.

AFAIK 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 to assume 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 does exactly fit in "other authentication requirements"? Isn't this any client that has to be auth'ed?

I've been going through some docs 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 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 to assume 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 does exactly fit in "other authentication requirements"? Isn't this any client that has to be auth'ed?