Hello @ihugo,
It is probably related with IdentityServer published on http instead of https. IdentityServer must be deployed to https. Can you check issuer under /.well-known/openid-configuration?
You can check here about how to set it.
If that is not the case, can you share the logs under your Logs folder by executing into your container?
@GregB
It is not possible to re-produce nor diagnose without checking azure web-server logs to see what is happening during identityserver callback.
Can it be related with azure tiers?
Hello,
What I don't understand is how the profile page is relevant to the new auth mechanism
You are signed in to Authorization Server (STS) which is responsible for user store/account info. After signing in, redirecting back to your application with the related data about the signed in user. It is pretty common and realistic to keep account pages inside authorization server. Since it is a SSO, why not leverage from it (like you said yourself as google, microsoft or any other distributed application) instead of writing same account/profile pages for each application again and again?
It also provides easy scaling on applications, here is an example probably you already came across before:
*We completed our first web application, now we need to create an other application and they need to interact with each other. And ofcourse users should be able to login with their existing credentials *
It is not a good practice to give every newly created application the ability to modify user related data which is in Authorization Server domain.
AppConfig (39.4k) seems to be loaded in ~200 ms
Login request begins..
Timeout after 3.8 min..
Can you confirm that this problem only occurs on azure and not in local? Can you check azure web server logs if anything logged during this period?
Hello,
Can it be related with your redis server? Can you check if redis is up and matches with your redis config?
Can you override OnPostExternalLogin method as the sample I mentioned to check what the ModelState is about?
Hello @edelivery,
My purpose when using angular-oauth2-oidc is to want to get token after login. Please let me know how to get tokens
I assume you mean getting AccessToken. You will already have it stored in local storage after login completed but your authentication flow is blocked because of invalid redirect url which is related with your client configuration as @alper mentioned above.
Can you clarify what exactly you want to achieve?
Hello @vishalnikam,
It seems your application can not reach to IdentityServer4. Can you check your identityserver .well-known/openid-configuration that it is reachable and authority matches with your application configuration; especially both are running on https?
Hello @nhontran,
the login option is shown in Identity Server B login page:
Can you check if you have returnUrl parameter on your address bar after navigated to Application A Login Page?
the page had navigated to the Identity Server A login page, I logged in successfully, however, it keeps navigate back to the Identity Server B login page, it should redirect me to application page or registration page if user is new.
User will already be registered with external provider, this is some different page for business rule i assume.
Either return url is not set or getting lost at the flow. Need more info to check it. But you can also modify the flow as you like with overriding the LoginPage of Application B like explained in this article.
For example, you can override this method below and check or manipulate to redirect to your dashboard whichever page you like.
public override Task<IActionResult> OnGetExternalLoginCallbackAsync(string returnUrl = "", string returnUrlHash = "", string remoteError = null) { return base.OnGetExternalLoginCallbackAsync(returnUrl, returnUrlHash, remoteError); }
Hello Mike,
Roles, permissions, operations; generally whole authorization aspect varies according to the context it is used and in the business rules it is dealth with. In some application you can see users logging to that system with different roles they have (mostly in legacy RBAC systems); in some other systems they login with same account and authorization is handled by operations, permissions, claims etc.
If I understand your idea correctly, you want to distinguish user roles and organization roles. So that organization unit roles can be extended from user roles. However this will only complicate the authorization even more.
How about moving the "Restricted Access" logic to claims and build around it? May I suggest you to check out role claims if it can suit your purpose?
