log in workspace manager and cloud sync, store refresh key, oauth pkce flow like

[Weixuanf]

https://cloudentity.com/developers/basics/oauth-extensions/authorization-code-with-pkce/ We may not need both code verifier and encrypted code challenge, let's directly send one code challenge without encryption.

1. add login button in dropdown menu
2. generate random codeChallenge, window.open(comfyspace.art/oauth/authorize?codeChallenge=randome_generated_code) in popup window to login
3. after success login, redirect to callsite with #code=xyz
4. client get the code then POST fetch(comfysapce.art/oauth/token, {code:xyz, codeChallenge:xxxxyyyyzzzz}
5. In server, verify the code and codeChallenge is indeed correct as before authorized, and in Session Table, sessionTable.put({id: userID, refreshToken: random_generated, accessToken: random_generated }) return refreshToken and accessToken to client
6. encrypt refreshToken and store in localstorage, in a tokenUtils.ts, export function encrypAndStoreRefreshToken(), decryptRefreshToken() ADD tokenUtils.ts, INTO .gitignore, DO NOT commit tokenUtils.ts
7. accessToken only store in RAM (react context, variables), each refresh, use refresh token to refetch accessToken if accessToken expired

Let me know if this auth flow sounds good to you, looking forward to your feedbacks @arslan2012

[Weixuanf]

From GPT:

In OAuth 2.0 with PKCE (Proof Key for Code Exchange), the mechanism involves both a Code Verifier and a Code Challenge to enhance the security of the authorization code flow, especially for public clients that cannot securely store their secrets. The primary reasons for using both, instead of just a code verifier, are to prevent interception attacks and to ensure that the entity exchanging the authorization code for an access token is the same entity that initiated the authorization request.

Here's a breakdown of how PKCE works and the roles of the code verifier and code challenge:

Code Verifier

• The Code Verifier is a high-entropy cryptographic string (randomly generated by the client) used to mitigate interception attacks.
• It is created by the client before initiating the authorization request and is used later in the flow to prove the identity of the client making the request.

Code Challenge

• The Code Challenge is derived from the code verifier by applying a cryptographic transformation (S256 transformation, which is SHA256 hashing, or plain transformation, which is using the code verifier as-is). This transformation ensures that even if the code challenge is intercepted, without the exact transformation method and the original code verifier, it cannot be used by an attacker.
• It is sent in the initial authorization request to the authorization server (/authorize endpoint).

Authorization Flow with PKCE

1. Client Creates Code Verifier and Code Challenge:

   • The client generates a code verifier and then creates a code challenge from this verifier.

2. Client Requests Authorization (/authorize):

   • The client sends the code challenge to the authorization server when it makes the authorization request. This step is critical because it ensures that only a client with the correct code verifier can later exchange the authorization code for an access token.

3. Authorization Server Responds:

   • If the user authorizes the request, the authorization server issues an authorization code to the client.

4. Client Requests Access Token (/token):

   • To exchange the authorization code for an access token, the client sends a request to the token endpoint. This request includes the authorization code and the code verifier.
   • The server uses the code verifier, applies the same transformation used to generate the code challenge initially, and verifies that the result matches the code challenge it received earlier. This proves that the client making the token request is the same client that initiated the authorization request.

Why Not Just Use the Code Verifier Directly?

• Security: Sending the code verifier directly in the authorization request would expose it to potential interception. Using the code challenge (especially with the S256 transformation) instead adds a layer of security, making it difficult for an intercepted code challenge to be useful without also obtaining the original code verifier.
• Integrity: This process ensures the integrity of the flow by verifying that the client exchanging the authorization code is the same client that initiated the request. It prevents an attacker who intercepts the authorization code from exchanging it for an access token without also having the code verifier.

In summary, PKCE strengthens the security of the OAuth 2.0 flow by ensuring that the authorization request and token exchange are tied to the same client through a verifiable challenge-response mechanism, thus mitigating interception attacks and unauthorized access token exchanges.