openiddict / openiddict-samples

.NET samples for OpenIddict

Home Page:https://documentation.openiddict.com/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Creating a sample with multiple clients of differing vintage against a single validation server

dlandi opened this issue · comments

Confirm you've already contributed to this project or that you sponsor it

  • I confirm I'm a sponsor or a contributor

Version

4.x

Question

Hi @kevinchalet ,

So my strange questions are caused by my need to create a single validation server against the latest DotNet version.

I need to use

  1. an ASP.Net 4.8 Owin Mortis client (to support legacy code),
  2. an ASP.NET Core 7 Velusia client to move the legacy code forward,
  3. a Blazor (Dantooine) client because I ultimately want to move the client code base to Blazor.

After trying various permutations, the Dantooine Server can support the other (Mortis and Velusia) clients.

Do you have any general advice about combining clients?

The Dantooine Client does not have a client database; what is it doing instead? How is it storing the same data?

@kevinchalet I just read this thread between you and Damien Bodh

So I now see that you do not recommend the BFF approach.

However, I haven't been able to get the Balosar server working with the other (Mortis, Velusia) clients.

I'll try again, but is there something missing from the Balosar server, prevent it to work with Mortis and Velusia clients?

Hey,

Do you have any general advice about combining clients?

Having a single or multiple clients doesn't make any difference as clients are basically independent from each other. Once you've configured things correctly, it should work for all your clients (assuming you don't add client-specific code in your custom authorization controller).

The Dantooine Client does not have a client database; what is it doing instead? How is it storing the same data?

The Dantooine OIDC client (i.e Dantooine.BFF.Server) uses the ASP.NET Core OIDC middleware developed by Microsoft, that doesn't offer native state token replay protection, unlike the new OpenIddict client that stores state tokens in the DB and returns a fixed-size reference ID (so that state parameters are much more compact, which helps avoid hitting limits enforced by some providers, like Twitter).

I should probably take some time to update it to use the OpenIddict client like the other samples.

I'll try again, but is there something missing from the Balosar server, prevent it to work with Mortis and Velusia clients?

Not that I can think of: it's a classical code flow with consent views + refresh token support implementation that should work with any client. What error did you see, concretely?

@kevinchalet I added you as a collaborator on that repo so you can edit it if you wish and upload the changes to make it work.

@kevinchalet wait, I think I found my error. One second, before you proceed.

@kevinchalet
Progress. I have several branches going, and for this branch, I forgot to correctly update the mvc.Client names (since both the original Mortis and Velusia client were both named "mvc".)

Now I have Velusia working on the Balosar Server but not Mortis.

I've updated the branch: https://github.com/dlandi/openiddict-samples/tree/unify-on-balosar-server

Here is the video: https://www.youtube.com/watch?v=sv7uPrpj1MU

Resolved