I have two webapi projects which will be deployed as two different websites on the same server - server/site1 and server/site2. They both use token authentication. Can I have a third webapi project with just the token endpoint that is deployed at server/tokensite so that the token retrieved from here can be used for authentication on site1 and site2?
I have two webapi projects which will be deployed as two different websites on the same server - server/site1 and server/site2. They both use token authentication. Can I have a third webapi project with just the token endpoint that is deployed at server/tokensite
I would prefer to deploy on same server, but using sub domains:
This gives you the flexibility to move things around servers more easily.
so that the token retrieved from here can be used for authentication on site1 and site2?
Yes you can, but as I already mention I wouldn't do it in the same domain.
So it seems that what you are trying to implement is Single Sign On(SSO)
Single sign-on (SSO) is a property of access control of multiple related, yet independent, software systems. Conversely, single sign-off is the property whereby a single action of signing out terminates access to multiple software systems. Other shared authentication schemes such as OpenID, and OpenID Connect offer other services that may require users to make choices during a sign-on to a resource, but can be configured for single sign-on if those other services (such as user consent) are disabled.
So to achieve SSO you can use OpenID Connect:
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly, and usable by native and mobile applications. OpenID Connect defines optional mechanisms for robust signing and encryption. Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself.
I don't advise you to implement your own solutions, instead delegate it to an Authentication provider, or use an Open Source package to implement it.
It seems you are using DOTNET, thus I would recommend you to read this quick start on their docs, that guides you through of setting up SSO in a new project with some official libraries.
In this quickstart, you'll learn how to implement sign-in with Microsoft using an ASP.NET MVC solution with a traditional web browser-based application using OpenID Connect. You'll learn how to enable sign-ins from work and school accounts in your ASP.NET application.
Alternatively you can use SSO from Azure Active Directory.
Single sign-on (SSO) adds security and convenience when users sign-on to applications in Azure Active Directory (Azure AD). This article describes the single sign-on methods, and helps you choose the most appropriate SSO method when configuring your applications.
For anyone reading this, but using other language, see some examples of SSO packages for:
Once you are deploying your own solution I would recommend you to invest heavily in securing it. For an API serving a web app you can employ several layers of defense, starting with reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) solution. If you want to learn and understand why is important to secure properly an API, you may want to read this series of articles, that will teach you how API Keys, User Access Tokens, HMAC and TLS Pinning can be used to protect the API and how they can be bypassed. While the series of articles are in the context of a mobile api, lot of it is still valid for a web api.
Google reCAPTCHA V3:
reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.
...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.
WAF - Web Application Firewall:
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
UBA - User Behavior Analytics:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.