Create a confidential client with pkce enabled

Questions
1

Hello the Okta team,

I would like to create a client in order to test PKCE on the top of a confidentiel client like explained in this post.

I try to create a confidential client with pkce enabled using the admin UI. I think that I have successfully created an confidential client thought the “Web” UI step but I saw nothing in order to enable the PKCE on it. On an other hand I have successfully created a public client thought the “SPA” UI step with PKCE enabled.

I can connect myself to the “SPA” client without the client secret. So I do not think that this is the good way.

I can also connect myself to the “WEB” application with no PKCE enabled on the client side.

I found nothing in the documentation but maybe the confidential client is by default PKCE enabled and can accept PKCE or not, adapting himself to the best way. Could you confirm me this ?

Regards,
Fabrice Dutron

2

Hi @fabrice,

PKCE code flow is used only in public clients to overcome the drawbacks of the implicit flow.
For a confidential client, that can make back channel requests, PKCE isn’t needed because the Authorization Code flow is secure and a securely stored client secret can be used to authenticate the client to the server.

You can read this for more information - https://developer.okta.com/docs/concepts/auth-overview/#choosing-an-oauth-2-0-flow

3

Hello Vijet,

Thanks for your response,

Following this comment and this one I thought that okta support PKCE for confidential clients as it’s requested by section 2.1.1. Authorization Code Grant :

Clients utilizing the authorization grant type MUST use PKCE in order to (with the help of the authorization server) detect and prevent attempts to inject (replay) authorization codes into the authorization response.

and :

Note: although PKCE so far was recommended as a mechanism to protect native apps , this advice applies to all kinds of OAuth clients, including web applications .

Always in my understanding I thought that the following spring security story Consider enabling PKCE for confidential clients and this pull request of Brian Demers (Okta) here was in order to improve the security for a confidential client.

But maybe this is only misunderstanding.

4

Hi @fabrice,

It’s a good question but I am trying to think where in the flow the authorization code interception attack can occur between the Authorization Server (Okta) and your Web Application (Private Client) provided the communication is secured by TLS end-to-end and you trust TLS offloading components. The RFC you linked points to RFC7636 which mainly talks about Public Clients.

It’s more of a question for my personal understanding than an answer.

Thanks,
Jatinder

5

Join our OAuth Happy Hour tomorrow, we’re going to be demoing exactly this attack and show how PKCE protects confidential clients too: https://oktadev.events/2020/05/oauth-happy-hour-4fW0HQ5dhflG

1 Like
6

Thanks, great demo. Maybe a post which resume the demo could be great (even without the code of the browsers extension).

In conlusion, what I understand (correct me if I’m wrong) is :

  • PKCE is needed even for confidential client and is by default set in an confidential okta client.
  • An confidential okta client allow an application to connect using PKCE or not.
  • You can not configure the client to force the use of PKCE by the application.

Note: I found no way to check in the okta log event that the successful connection used PKCE or not.