Open Closed

Functional questions: Migrating from IdentityServer to OpenIddict Step by Step Guide #4052


User avatar
0
Frontis2 created
  • ABP Framework version: v6.0.1
  • UI type: MVC
  • DB provider: EF Core
  • Tiered (MVC) or Identity Server Separated (Angular): no
  • Steps to reproduce the issue:"

After reading the migration guide... https://docs.abp.io/en/abp/latest/Migration-Guides/OpenIddict-Step-by-Step

Context We have multiple customers. Some of our customers have multiple clients (Administration => Identity Server => Clients) connecting to them. Therefor it is hard for us to test if the clients keep working. We don't have much influence on it.

So my question is.. Are there significant changes that occur, after the migration, that our customers need to report to their clients? Think about endpoint changes. Is there any difference in how tokens are handled?

As far as we know, all clients follow the openid / oauth2 specs. We did not implement custom code on the ABP side.

Another (small) functional question: Can created ABP users use their own password after the migration?

Thanks in advance,


4 Answer(s)
  • User Avatar
    0
    Frontis2 created

    Is my question to complicated? I know it is a bit abstract. However, knowing any pitfalls would help us a lot. If there is no known pitfall, I do like to know either.

  • User Avatar
    0
    gterdem created
    Support Team Senior .NET Developer

    What do you mean by customers? Are they your tenants in your multi-tenant application? If so, tenants do not have access to openid-provider management (identityserver or openIddict).

    IdentityServer or OpenIddict is not about user management, it is about application (client) management. So, users are managed by the Identity Module and they won't be affected. When you migrate to OpenIddict, you need to seed the applications (clients) only.

  • User Avatar
    0
    Frontis2 created

    @gterdem

    Thanks for your response.

    As a digital agency, we run multiple ABP projects, for multiple customers. And those customers (abp-projects), have multiple clients connecting to them. So multiple clients, that connect to our ABP api's.

    We did not make all clients, and therefore it is hard to test them. Is there anything that we should report to the developers of the clients? Other than "please test everything".

    Are there significant changes that occur, after the migration, that our customers need to report to their clients? Think about endpoint changes. Is there any difference in how tokens are handled?

    As far as we know, all clients follow the openid / oauth2 specs. We did not implement custom code on the ABP side.

    If this question is hard to answer, I also do like to know. Anything you know of, is desirable to hear.

  • User Avatar
    1
    gterdem created
    Support Team Senior .NET Developer

    First of all, if they are using access tokens valid for a long time, they will become invalid and they will need to re-login.

    I would recommend selecting a few of your customers and update them first as pilot customers step by step if possible. That should give the best idea.

    Are there significant changes that occur, after the migration, that our customers need to report to their clients? Think about endpoint changes. Is there any difference in how tokens are handled?

    Authorization endpoint stays same but the logout endpoint seems to be changed from /endsession (identityserver) to /logout. But I don't think you need to do something manually if you update the account module.

    As far as we know, all clients follow the openid / oauth2 specs. We did not implement custom code on the ABP side.

    It shouldn't be a problem. You can always report to us if anything we miss out on our migration guide.

Made with ❤️ on ABP v8.2.0-preview Updated on March 25, 2024, 15:11