Sounds great, Ben. I am glad that your desired authentication strategy is working well. Let us know if you need anything else in the future. Have a nice weekend 
My current backend is PHP. The way Iâve authenticated in the past has been to send an id_token to my https://ultrasoundjelly.auth0.com/tokeninfo endpoint:
<?php
$fields = 1;
$fields_as_string = "id_token=" . $token;
$url="https://ultrasoundjelly.auth0.com/tokeninfo";
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch,CURLOPT_URL, $url);
curl_setopt($ch,CURLOPT_POST, $fields);
curl_setopt($ch,CURLOPT_POSTFIELDS, $fields_as_string);
$result = curl_exec($ch);
$obj=json_decode($result);
$user=$obj->{'user_id'};
$name=$obj->{'name'};
curl_close($ch);
?>
Using your code I obtained a token with var id_token = authService.getAccessToken(); but get a NULL result from the above endpoint. Am I just mixing up my endpoints? Whatâs the proper way to handle backend php auth?
Same problem for me. @dan-auth0
Not allowed to load local resource: file:///callback?code=oK8o9GjG-Z9gPD3
1 Like
OK, I see now that this token is a JWT. Question for you: is the validation and decoding method outlined here sufficient to verify this token hasnât been altered? It would seem that using RS256, without a signature, that this JWT could be theoretically produced or altered by a third party.
1 Like
Ben, we recommend for the ID Token to be consumed by the Client Application, in this case an Electron app. To process authorization in the backend, in this case a PHP backend, we recommend using an Access Token.
Both the ID Token and the Access Token are returned to the client after a user logs in. The Client Application can use the ID Token to get user profile information, for example. When the Client Application needs to make a request to a protected API endpoint, it needs to send the Access Token with the request. Your PHP backend would be set up to consume the Access Token to determine the authorization status and access level of the Client Application making the request.
Here an example on how to protect a Lumen API using Auth0: Developing RESTful APIs with Lumen (A PHP Micro-framework)
Lumen is a PHP microframework.
You can also follow this tutorial from our docs to see how you can use PHP with Auth0 without a framework:
Howdy, Simone. Welcome to our Auth0 Community.
Are you having the same issue as @jgisclair?
What operating system are you using? At what part of the tutorial you started to see this error?
Thank you!
@dan-auth0 Thanks again for the direction, Dan. I see the id_token returned in the response, and added a function to auth-service to expose this to my renderer code. Following the tutorials you linked, my question still remains. Once verified and decoded, the id_token contains the info I need, yet I still fail to see how itâs secure without verifying against some secret key. I see that when decoded, this JWT has a https://www.mydomain.com/access_token value. Should I do something with this?
@dan-auth0 @jgisclair
electron: 7.1.10, os: mac os 10.15.2
Finally, after 2 days, i found the issue. Basically âwebRequest.onBeforeRequestâ doesnât intercepts the request:
file:///callback*
I donât know exactly why it doesnât work, maybe because this request is executed from a different contextâŠ
Anyway, the solution is to replace:
const filter = {
urls: [
âfile:///callback*â
]
};webRequest.onBeforeRequest(filter, async ({url}) => {
await authService.loadTokens(url);
createAppWindow();
return destroyAuthWin();
});
with:
const { protocol } = require(âelectronâ);
protocol.interceptBufferProtocol(âfileâ, async ({url}) => {
if(url.includes(âfile:///callback?codeâ)){
await authService.loadTokens(url);
createAppWindow();
return destroyAuthWin();
}
});
Thanks,
Simone
3 Likes
oooo perfect to hear that! Thanks for sharing the solution!
Thank you for sharing this troubleshooting information, Simone
What is strange to me is that I am not getting the issue to manifest itself on my app. I will run the tutorial again as-is and see if it comes up.
How do you see the problem in question? Would you mind sharing a screenshot of where the problem manifests, please?
Thank you!
@dan-auth0 I was actually wrong, Iâm still seeing this bug. Hereâs what I do to reproduce:
git clone https://github.com/auth0-blog/electron-openid-oauth.git
cd electron-openid-oauth/frontend/
cp ~/mycreds/env-variables.json .
npm install --save-dev electron-rebuild
$(npm bin)/electron-rebuild
npm start
Then login with an existing gmail account. Strange thing is: it doesnât happen with all gmail accounts. Hereâs a video showing what happens.
This is super helpful. Thank you, Simone! 
One more question, please: whatâs are your dependencies like? Could you please share your package.json? Thanks!
Are you doing email/password login or Social Login, Simone? I am consulting this with one of our Solution Engineers
only email/password login for now. I havenât used Social login yet.
Let me know if i can help you to reproduce this issue on your side
1 Like
I think I finally was able to reproduce it. Itâs happening with Electron 7. I also upgraded to Keytar v5.
I will try your solution now 
2 Likes
Simone, I am integrating your solution but I am getting a blank screen after logging in
This is how I updated frontend/main/auth-process.js. Does it look good to you? Thanks!
1 Like
Hey Dan, I was having the same problem as Simone and now am getting the blank screen like you. Will keep an eye on this thread as Iâm looking forward to resolving this.
1 Like
Are there any updates on this? This intermittent bug is rendering my app unusable. Thanks in advance.
1 Like