Passing an auth Token to a second client for API access to a .NET Core 2 server flow issues

Help
, ,
1

I’ve made several different attempts at this with various flows and can only get so far. I am new to Auth0 and OIDC and believe that my approach is incorrect and require guidance on the best way to implement this. I have a requirement which I could attempt to implement manually but would prefer to use Auth0 as much as possible.

The scenario is as follows; I have implemented Auth0 OIDC authentication on a .NET Core 2 server as per the tutorials. I have this implemented and working, the user can authenticate through the SPA using Lock and their account is linked up with a local account on the server.

I also have a native client written using Electron, again I have implemented the login using Lock and it works without issue to the server.

Now the part where I am struggling and I haven’t been able to solve; I have a 2nd client written in Unity, I have set it up so that I can pass in arguments to the application when being launched from the Electron client. The idea being that I will be able to pass over authentication credentials in the form of a token. I can then use this token to send data to the server from the Unity client without having to log in again or having to create a new token. I have attemted this with the Access Token but it is failing witha 403. I am considering generating a custom Token on the server and returning it to the client at login which I will then check on every request and temporary save it to the users profile but I feel that this should already be the job of the access token.

Does anyone have any suggestions on how I should implement this? Am I right in saying that the Access token should be able to do this? If so then it must be an issue with my implementation.

2

Focusing on the Electron and Unity situation, in general sharing tokens issued to one application in another is not correct. However, if this is a case that in fact both Electron and Unity is perceived to the end-user as the same application and the different frameworks are just an implementation detail than it could be an exception to the above guideline.

As you mentioned, given that the access tokens being issued are bearer tokens from a technical perspective any party that posses the token would be able to call the associated resource server with success; this means that the 403 might be some implementation issue. In conclusion, depending on the exact characteristics having Unity act as an independent client application that takes the user through login again (even if SSO can be leveraged) could the best approach, but in some scenarios the reuse of tokens could be feasible. What I would likely never do would be enter the realm where you’re issuing tokens yourself in your own systems.