Should Authorization flow use both secret and PKCE for a Web app

user_7957165 0
Viewed 900

I'm currently looking at the different OIDC flows and found AuthorizationCode flow and AuthorizationCode flow with PKCE.

Almost all places that I found said that the PKCE is a replacement for the Client secret and should be used by native applications.

Now i'm wondering what reason there is to not use a client secret and PKCE, would this be usefull or is this just not necessary?

I'm running an Openiddict server that i've tested will check for both the client secret and the code verifier. But everywhere i read, it just says PKCE and no (static) secret.

oauth-2.0 openid-connect openid
1 Answers

Almost all places that I found said that the PKCE is a replacement for the Client secret and should be used by native applications.

Definitely not. PKCE and client authentication are two additive but completely separate measures:

  • Client authentication - which is typically used by server-side clients - guarantees that only the client application the authorization code was issued to can redeem it. With this security measure in place, even the resource owner himself cannot redeem his own code.

  • PKCE guarantees that only the client that initiated an authorization request can send a valid token request, since the authorization code is bound to the initial code challenge/verifier that is only known by the legitimate client that generated it. With mobile/desktop applications, PCKE is particularly useful to prevent attacks that rely on modifying the URI schemes handled by a specific application, that may be hijacked to re-reroute an authorization response and steal the authorization code.

These days, we also tend to use PKCE in confidential server-side apps to prevent authorization code leakages, even though it was originally designed for public apps like mobile or desktop apps. In this case, you should definitely combine it with client authentication (i.e client secret validation).

user_5427570
Related