I am using Identity server 4 for authentication. When I use my IS4 login then after authentication of the user, user get redirected to the MVC client. But when the user uses Google Authentication for the same MVC client. Then after google authentication user don't get redirected to the MVC client, the user stays on the authentication server's login page?
Related
I'd like my Blazor WebAssembly app to authenticate against an OpenID Connect (OIDC) server. The users should enter their username and password directly in the Blazor WebAssembly app rather than redirected to the server for authentication. Authenticated users should be granted a JWT for further communication.
Can someone provide a tutorial on how to implement this flow properly?
The Blazor WebAssembly app is hosted with ASP.NET Core, which has an OpenIddict authorization server.
I have a Blazor Server app which wants to connect to a .Net Core WebApi. The app should send an authentication request and the WebApi returns a JWT containing user data. For any further communication with the WebApi the JWT should be used to authorize against it.
I'd like to ensure that only authenticated users can access the server app. If someone is not authenticated he or she should be redirected to a login page.
Up to now I've used a combination of default Identity with AzureAD authentication.
Is there any option to have a JWT authentication working the same way?
I have an Asp.Net Core IdentityServer4 instance securing an API that is fronted by a Vue.js SPA (using oidc-client). The IS4 server is setup to manage "local" account itself for my companies users, but we also have an external OIDC provider setup for a trusted partner that allows their users to access our site using their single sign-on server (OIDC identity server). The partner's portal has a link to our app, so if they are already authenticated by their own OIDC server, then no additional login prompt is displayed.
Overall, this process works. I can login "locally" (an account that is only on our identity server), or use the external OIDC provider that authenticates the user and goes through the auto-provisioning on our local IS4 server. The Vue app has its tokens and silent refresh is enabled, which keeps the user's credentials updated against our IS4 server.
However, if a user from our partner comes to our app, spends some time there, and then returns to their own portal via a link on our site, it's likely that their access will have timed out and they see their own SSO login again. This is because the silent refresh on our site is only refreshing our local IdentityServer4 credentials.
Is it possible to somehow maintain BOTH "sessions" while the partner user is on our site? Silently refreshing both our IS4 token and their OIDC SSO credentials?
I am using IdentityServer4 to secure my API and also to authenticate users, the client is the main ASP.NET Core MVC App, I just want the login interface and UI to be at the MVC App and the login implementation at the IdentityServer, so the IdentityServer must have an API to just receive username and password from the MVC app login page return the token which will be used in cookies
It is a bad idea to move your views for several reasons. Some of them:
If you move the views to your MVC client you will have to create those views in all your clients.
OAuth2 / OpenId Connect should delegate authorization / authentication to your Idp to avoid credentials sharing. Instead of that, you are forced to use Resource Owner Password Credentials which implies that we cannot use the user's consent pages from the Idp.
You won't have Autentication Cookie from your Idp for Single Sign On.
Our system architecture has this setup. We have an API that is used by a WebApp Client. We allow users to authenticate using an Identity Provider (IDP) that returns SAML.
The problem is how would you setup authentication? Which of the flow below would be more suitable?
WebApp Client controls the flow
When a user needing authentication visits WebApp Client, redirect user to IDP.
User authenticates with IDP
IDP redirect user back to webapp client with SAML response
WebApp client passes the SAML to the API.
The API will decrypt and read the attributes.
API then gives access token to the WebApp client it can use for subsequent requests.
API controls the flow
When a user needing authentication visits WebApp Client, redirect user to a special endpoint of API.
API redirects user to IDP
User authenticates with IDP
IDP redirect user back to API with SAML response
API decrypt and read the attributes
API redirects user to the WebApp client passing an access token to the WebApp client it can use for subsequent requests.
I'm currently asking myself the same questions with google idp. I thought about passing the returning code from idp to my API and then authenticating the user from my API.
If you have some return on your experience let me know :)