I am running a third-party simple web app, that does not support/require user-management, as a service on a server that I control (self-hosted). However I want to allow only users with valid username/password to access that service.
Is there a simple way to protect servers with a login page?
Preferably, something like login using Google Workspace credentials or some other identity provider would be great.
Related
Background
I have a web application "APP1" (front-end: Vue.js & Back end:Azure function) deployed in azure app service. I have implemented client directed sign in (easy auth using this), after that I can authenticate user using provider's sign in page [both AAD & google].
Target
I have another web application "APP2" deployed in on-primes server. I want to redirect to APP1 from "APP2" and automatically sign in without provider's sign in page. I will read credentials from environment variable.
Tried solutions
I have found a similar issue here, however I am unable to use the solution because the DB between AAP1 and AAP2 can't be shared
I have also checked the google identity providers documentation, however I am unable to find how to programmatically sign in without provider's sign in page
Question
Is it possible to programmatically sign in to google identity to get token without provider's sign in page
The whole point of google identity is to prove the identity of the person behind the machine.
OpenID Connect is an open standard that companies use to authenticate (signin) users. IdPs use this so that users can sign in to the IdP, and then access other websites and apps without having to log in or share their sign-in information. (id_token)
OAuth 2.0. This standard provides secure delegated access. This means an application created by a developer, can take actions or access resources from a server on behalf of the user, without them having to share their credentials (login and password). It does this by allowing the identity provider (IdP) to issue tokens to third-party applications with the user’s approval. (access_token, refresh_token)
I'm creating a small web app running on IIS and I need to implement a secure way to handle login authentication against active directory.
Currently, I have it set up with Windows authentication, so when users first go to the website it shows the login prompt from the browser, they login using their AD credentials, and then it allows them into the site.
However, I want to have an actual login page and have these credentials validated against AD instead of Windows Authentication. I've been researching for hours about LDAP but I can't seem to find good documentation/videos on how to set it up to communicate with AD. I've thought about using 3rd party services like Okta but I don't think I need to.
Does anyone have any ideas?
I've created an OpenID Connect identity provider using ASP.NET Core and IdentityServer4 and published it to Azure. I can authenticate with the provider using an MVC app that's hosted on my Azure VM, however, when I try to run the same app and access my provider from my local PC I run in to a 404 error. My provider website partially displays and looking at the traffic in MS Edge, my client app is successfully authorized via the authorize endpoint. CORS is also enabled for my client app with a record in ClientCorsOrigins. Looking for any ideas on how to get past the 404 and to the login screen for my identity provider.
Is your IdentityServer really available and reachable outside Azure?
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?
Should be a simple matter of registering the app in the IBM Cloud and providing callback URIs for authenticating the user and returning control just like login with google or login with Amazon.
But I cannot seem to find the exact flow of steps involved.
--prasanna
I think the service you are looking for is App ID.
When you are developing a web application, you can use the App ID web flow to securely authenticate users. Users are then able to access your server-side protected content in your web apps.
App ID uses the OIDC authorization code flow to securely authenticate users. With this flow, when the user is authenticated, the app receives an authorization code. The code is then exchanged for an access, identity, and refresh token. In code exchange step the tokens are always sent via a secure backchannel between the app and the OIDC server. This provides an additional layer of security as the attacker is not able to intercept the tokens. These tokens can be sent directly to the web server hosting application for user authentication.
App ID interacts with identity providers by using multiple protocols such as OpenID Connect, SAML, and more. For example, OpenID Connect is the protocol that is used with many social providers such as Facebook, Google. Enterprise providers such as Azure Active Directory External link icon or Active Directory Federation Service External link icon, generally use SAML as their identity protocol. For Cloud Directory, the service uses SCIM to verify identity information.
Read this blog post for using a custom identity provider
For an in-depth understanding of the flow, you can refer to this link