Any example with "state" parameter instead of using a code verifier?

[walidmahade]

I am trying to integrate with vipps login. They their code example/api docs they don't use the code_verifier or code_challenge.
Is it possible get the token response without those?

If I do send those along with the recommended params, i get invalid_grant error in authorizationCodeGrantRequest():
{ "error": "invalid_grant", "error_description": "The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client. invalid_token" }

Any suggestions?

[panva]

I cannot speak to any particular authorization server vendor, but if they don't support PKCE then they don't fall under the profile this software and current best practice expects and you ought to look for another software to interoperate with that vendor.

[AlexErrant]

Somewhat ironically this includes GitHub:

The PKCE (Proof Key for Code Exchange) parameters code_challenge and code_challenge_method are not supported at this time.

Using a nonempty string (e.g. "x") seems to work for them (and oauth4webapi (which complains if codeVerifier is empty)), though:

const response = await authorizationCodeGrantRequest(
    as,
    client,
    parameters,
    "https://localhost:3014/api/auth/callback/github",
    "x"
  )

[panva]

The expectation is you would use pkce as if it was supported tho. Because with a fixed string like so when pkce support is added your code breaks.

PKCE is backwards compatible. Using it with non supporting server does not break the flow. If the server is doing regular oauth correct that is.

[xdivby0]

Using a nonempty string (e.g. "x") seems to work for them (and oauth4webapi (which complains if codeVerifier is empty)), though:

const response = await authorizationCodeGrantRequest(
    as,
    client,
    parameters,
    "https://localhost:3014/api/auth/callback/github",
    "x"
  )

I have used something similar as well to test if everything else works (which seems to be the case). I can also see how a code_verifier is necessary when deploying to a frontend-only or desktop app without a server, because we can't hold a secret securely there.

Is this also the way it should be done for server applications? I already have my client secret for making sure no one else can read the authorization_code, or did I understand that wrong?

I am asking because my backend is stateless and I don't want to create a new database model for the verifier and check that table regularly to delete all non-used ones.

So I guess my question is 1. is this need / can I use this package without a code_verifier? 2. Is the solution of having a hardcoded "x" a security flaw (if yes under what circumstances).

[xdivby0]

It's intended, okay - what are the implications of doing it the hard-coded "x" way? Who would be able to read what?

[panva]

A hardcoded value only "works" as long as your provider doesn't actually support pkce. When they'll eventually do, your authentication request flow will break.

Use PKCE correctly.

[xdivby0]

Understood - I think I'll create a database schema and regular check to cleanup unused verifiers then, seems like the only possible solution to use PKCE on a stateless backend like cloudflare workers/pages

[panva]

You still use cookies to carry the session, don't you?

[xdivby0]

No, I only need the oauth stuff on the server to retrieve user data when the user is not online.

If you are referring to my normal session auth, this is done via cookies but not oauth, the app auth is custom and super simple

[MellKam]

@panva Hi! I have the same problem with the Spotify auth server. I want to use authorization code without PKCE extension, but with this library I can't do that. In my case, I'm making requests from the server, so I dont need to worry about token to be stolen or client secret to be exposed.

I can't put some arbitrary value in code verifier because spotify supports pkce.

I don't want to use PKCE, because then I would have to update the refresh token every time I need to get a new access token. I would like to just put my refresh token in env and use it. PKCE just makes it harder for me to do that.

Why do you not want to support a plain authcode? Is there any reason for this?

[panva]

I have the same problem with the Spotify auth server.

Not the same...

I want to use authorization code without PKCE extension, but with this library I can't do that.

That's very much intended. The API design leads you to using PKCE and hopefully using it correctly for its many benefits that go beyond its original intention as shown by recent security analyses and the security bcp that's about to be finalized soon as well.

I can't put some arbitrary value in code verifier because spotify supports pkce.

Then use PKCE properly. Noone suggests to use arbitrary values anywhere to get around having to use pkce. Even when unsupported by the server pkce can be used by the client correctly, albeit then in conjunction with state.

I don't want to use PKCE, because then I would have to update the refresh token every time I need to get a new access token. I would like to just put my refresh token in env and use it. PKCE just makes it harder for me to do that.

PKCE has no interaction with the refresh token grant so I don't quite follow you from this point onward. PKCE does nothing to the auth code flow beyond the access token response to the authorization code grant request.

In pure auth code you would use state to protect your app from CSRF, when you use (and the server supports) PKCE state is not necessary and the same mechanism you'd use to carry over state is to be used to carry over the nonce verifier. The only difference is that pkce is server enforced which is in general safer than letting clients make decisions.

Why do you not want to support a plain authcode? Is there any reason for this?

I only wish to support modern and secure best practice flows that don't lead to developers footgunning themselves.

[MellKam]

If "PKCE has no interaction with the refresh token grant" then the spotify team implemented it wrong way.

Maybe I sould clarify how it works now. If I receive a refresh token with "plain auth code" I can make many access tokens from it. But if I use PKCE extension, I can only make one access token.

[panva]

From a very cursory look at their docs they simply employ refresh token rotation for what they see as public clients. It's not needed for confidential clients so them conditioning it by pkce which has become a general use extension is quite possibly a mistake on their part.