OAuth2: Is it good practice to store multiple information in state parameter then encrypt it?

[agh372]

I’m implementing the Authorization code flow with PKCE and planning to have my redirect_uri as the backend.

In this case, while making the code to token exchange call (in the backend), I won’t be having information like the clientId and code verifier.

In the Auth code request, we’re passing the state parameter, which gets returned back as a response in the backend via a redirect.

So, I’m planning to have my state parameter as

{
  "clientId":"test-client",
  "targetUrl: "profile",
  "codeVerifier":"xHchbhBDFJFhhDgbujFFfgVfGBffdfTKS"
}

and probably encrypt it and pass it in the authorization code request in the front-end.

Then when I receive the code and state in the backend, I can decrypt this in the backend and make the code to token request calls.

If this is an acceptable practice, what would be a good encryption method?

I tried RSA encryption, but I guess the data shouldn’t be more than 117 bytes, so I was thinking of AES encryption.

Or is there any better solution to get this information in the backend?

[erik]

Hello,

Typically you would have the backend generate the PKCE/state values before the client downloads/renders the widget (or you own form). If the frontend is a SPA app this information could be obtained with a AJAX call to your backend when the user navigates to the login page/form.

The backend server should have this state value saved so when the browser redirects to it with the authorization code/state the server can verify the request and pull any saved state for this request (code verifier / where to redirect the user to after auth / etc).

• Spring example of backend generating the state value (could be extended to also generate code challenge/verifier for PKCE)
• GO eaxample of backend generating the state value (could be extended to also generate code challenge/verifier for PKCE)