feat: oidc proxy, handle authRequest, callback

[peintnermax]

Adds OIDC functionality by implementing a proxy for relevant oidc endpoints and executes a callback at the end of an auth flow.

Closes #30

Definition of Ready

• I am happy with the code
• Short description of the feature/issue is added in the pr description
• PR is linked to the corresponding user story
• Acceptance criteria are met
• All open todos and follow ups are defined in a new ticket and justified
• Deviations from the acceptance criteria and design are agreed with the PO and documented.
• Jest unit tests ensure that components produce expected outputs on different inputs.
• Cypress integration tests ensure that login app pages work as expected. The ZITADEL API is mocked.
• No debug or dead code
• My code has no repetitions

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
typescript-login	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 28, 2023 1:04pm

[sPaCeMoNk3yIam]

Hi @peintnermax, thnks a lot for bring this topic forward! I currently myself, also using nextjs, am trying to build our own login UI, following the docs and this PR.

For the proxied OIDC requests I wonder, what should happen to the set-cookie headers of the underlying Zitadel API instance responses. I see that the domain of these cookies is still set to the Zitadel API instance (which is on a different host), which would mean, that they are never sent by the client when going to the login UI, as the client never directly requests from the Zitadel API, but through the login UI' backend/proxy.

Of course, the browser won't even set the cookie, as the hosts don't match in the first place.

So, are these cookies relevant, and if so I suspect the host/domain needs to be adjusted as well before returning the response to the client?

I also started a thread on discord: https://discord.com/channels/927474939156643850/1156239247322402876

[peintnermax]

Hi @peintnermax, thnks a lot for bring this topic forward! I currently myself, also using nextjs, am trying to build our own login UI, following the docs and this PR.

For the proxied OIDC requests I wonder, what should happen to the set-cookie headers of the underlying Zitadel API instance responses. I see that the domain of these cookies is still set to the Zitadel API instance (which is on a different host), which would mean, that they are never sent by the client when going to the login UI, as the client never directly requests from the Zitadel API, but through the login UI' backend/proxy.

Of course, the browser won't even set the cookie, as the hosts don't match in the first place.
So, are these cookies relevant, and if so I suspect the host/domain needs to be adjusted as well before returning the response to the client?

I also started a thread on discord: https://discord.com/channels/927474939156643850/1156239247322402876

Hi @sPaCeMoNk3yIam ,
so the cookie you mention comes from the old login UI. Its has no use in the new resource APIs 👍