- 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)
-
0
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.
-
0
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.
-
0
@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.
-
1
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.
