If you’re only using database connections then you could consider using the resource owner password credentials (ROPC) grant to directly exchange user credentials for tokens; this would not require a browser-based flow. However, for new client the grant types required to accomplish this are not enabled by default because , in general, the browser-based flow is recommended as it means the client application does not have to directly process user credentials and in this way end-users are educated to only provide the credentials at one place (your associated login page and through a browser).
If you’re okay with the above considerations you can enable the required grant types and perform ROPC instead from the client application.
In relation to the problem you mentioned where there’s a Success Login, followed by a Failed Exchange, that situation could be explained by the following:
- you’re using a browser-based flow which involves a user authentication step through the browser and additional exchange of a code for the tokens.
- the user authentication steps is completed with success generating the corresponding log entry.
- the exchange step then fails generating the corresponding log entry.
The most common cause for this sequence of events is an incorrectly configured client application. A Windows Forms application should be represented in Auth0 as a Native client application type which has the side-effect of setting token endpoint authentication method to None.
If the client application is not correctly configured it can be setup to have a token endpoint authentication method other than none which would require the client secret to be sent during the exchange of code per tokens; since it’s a native application, they are unable to maintain that secret secret so you are only providing the client identifier which would then trigger the Unauthorized error.
Ensure that you set the client application type to Native.