Looking for some System Design input
Out current plan is to build a system that includes a Client and a Local Server both running on the users machine, and an API Server that both speak to (Client Read Only). The API Server will also need to update user metadata for the current user of a given request.
I would include a diagram but I seem unable to embed or link it.
My current understanding is that the Client and Local Server need to be ‘Applications’, and the Local Server and API Server need to be ‘APIs’ so that I can issue an access token with them as the audience. Since the client and local server are running on the client machine, I don’t think I can use a Client Secret, so both will need to do a PKCE login flow on start-up to be issued their tokens.
As a result of this, the Client needs to be able to run it’s own localhost server to receive the PKCE callback, and the client login requires two consent dialogs for the two required access tokens. My question is whether there is any way to avoid either the multiple consent dialogs, and the Client needing to run it’s own server, if possible maintaining the components of the design (Client, Local Server, API Server), or otherwise with a completely different direction?
Any input would be greatly appreciated.
Hi @nathan_d,
Welcome to the Auth0 Community !
Firstly, the approach to your use case looks to be well structured.
When it comes to skipping the user consent page, you can follow the guidelines listed on this Knowledge Article about Disabling the Consent Screen for Profile when Logging into Auth0 Applications, so you should be able to maintain you proposed architecture this way, with your client app having a callback URL to your localhost as well, and not have multiple consent screens.
I hope this helps and you have further questions please feel free to ask!
Best regards,
Remus
Hi @remus.ivan,
Thanks for the response, I’ve confirmed that both applications that will run on the client’s machine are first party. I believe the consent dialogs are shown because of the localhost callback as part of the PKCE login flow, which according the docs is not able to be bypassed:
Docs: /get-started/applications/confidential-and-public-applications/user-consent-and-third-party-applications#skip-consent-for-first-party-applications
Note that this option only allows verifiable first-party applications to skip consent at the moment. As localhost is never a verifiable first-party (because any malicious application may run on localhost for a user), Auth0 will always display the consent dialog for applications running on localhost regardless of whether they are marked as first-party applications.
This is why I’m wondering if there is an alternate design where the API server somehow receives the callback instead, and passes the tokens back to the user machine by a different method. If not then I guess we’ll have to live with the consent dialogs on login.
Hi @nathan_d,
You are absolutely right in regards to the statements mentioned above, so skipping user consent in it’s entirety is not suitable for this architecture. Focusing on this particular issue though, I believe an option that would fit your use case would be Configuring a Logical API for Multiple APIs. The steps provided by this Article outline how scopes can be defined that would correspond to the actions available on your actual Local Server and API Server. This way a single token will be issued, and your respective APIs would check if the specific scopes are included in the token.
With this approach, the user will interfere with a single consent screen that requests all the required scopes for your API calls, while maintaining the PCKE flow with a localhost server.
I hope this better suits your requirements.
Thanks,
Remus