Code Verifier Storage and Retrieval

For the Auth0 Authorization Code flow with PKCE, I have been using the domain company.us.auth0.com/authorize... to initiate the PKCE flow and I redirect to a callback on my server, /oauth?code=..., and can retrieve an access code from the query params. The next step is to send the code and code_verifier to /oauth/token, but I do not currently have a way to retrieve the code_verifier.

Do I need to update the flow so that my native app sends the code_verifier to my server for storage and have my server send the request the /authorize? And after my server gets an id token, access token, and refresh token, can the native desktop app use the code_verifier to poll my server for the values?

Note there is not an Auth0 SDK available that I can use and I am trying to work around that.

Hey there @milotis, good question!

Given there isn’t an Auth0 SDK for you use case, I’d be curious to know what sort of technology you are building this for - Do you mind sharing? Perhaps someone from the community speak from personal experience.

While the storage of the code_verifier is completely up to you, in the case of public clients (native + SPA) this is typically stored in memory and session/local storage respectively. Note that the code_verifier is used in unison with the code returned from the /authorize in exchange for tokens at the /token endpoint. Especially important here is that the code is only good for one use. Here’s a good step by step explanation of the PKCE flow:

Hope this helps!

1 Like

Thanks :slight_smile: I don’t understand the diagram because the [App] block appears to be doing stuff for the native application and the server from my apparent misunderstanding of how this flow works. I have a native app that generates a code verifier and code challenge and it opens the system browser to the /authorize endpoint. Also, the diagram from the Auth0 shows the Auth0 tenant sending the code directly to the App, but in my case that would go to the system browser or my server and I cannot retrieve values from the system browser from my native app. If the app in the diagram can send the Code Verifier and Code challenge and get an id token and access token, then I assume it must be safe for my native app to poll my server with those values to retrieve the access code, but I don’t see a way to map those values to the returned access code because it is the only value returned from the /authorize endpoint.

Unfortunately, the OAuth/OIDC flow as it relates to native desktop applications does introduce some additional complexity as you’ve noticed. Primarily, native desktop apps don’t have the luxury of relying on browser features like Chrome Custom Tabs (Android) or Safari View Controller(iOS) to perform OAuth related requests. Traditionally, many apps have relied on embedded web views to carry out OAuth related requests, but this is not encouraged as outlined in this video (discussed beginning around 10:18).

I believe this is where the an Inter-App URI or Private URI Scheme comes into play as referenced in both the linked specifications.

Hope this helps to clarify!

2 Likes

Thanks, again. Sorry, I have overlooked somethings while attempting to do this, but I have come up with a possible solution and would appreciate any feedback.

First, my native application opens the system browser to a URL on my server which saves the values of state, code challenge, and code challenge method. You would have to be logged in on the system browser for this to work.

Then, my server sends the client a redirect to company.us.auth0.com/authorize with the same parameters, but it has a callback to my server so I can append the returned code yielding (state, code challenge, code challenge method, code).

Finally, either my server can request an (id token, access token, refresh token) and append it to (state, code challenge, code challenge method, code) and the client can poll the server for those values using (state, code challenge, code challenge method) OR I could first let the native application poll for the code and send another request to generate the other tokens, but that seems redudant.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.