My set-up has the following:
This is a multi-tenant system, so the set of User Claims includes tenant_id which uniquely identifies the tenant that the user belongs to.
An IdentityServer4-based web-service (this provides OAuth2/OpenID Connect services): https://identity.example.com.
A separate web-service (RESTful web-api): https://random-number-generator-service.example.com.
A headless program (Windows Service) that runs on on-premises computers at many locations: RandomNumberConsumer.exe. This program makes use of random-number-generator-service in the context of a tenant_id so a user needs to authenticate at some point somehow but otherwise the program does not care about the user's details, only the user's tenant's details.
I understand this means that both random-number-generator-service and RandomNumberConsumer.exe are "clients".
Within IdentityServer all client software must be registered (either statically as a hardcoded list of Client object instances or with some kind of dynamic registration using a database to store client details. Obviously random-number-generator-service will have a static registration, but how should RandomNumberConsumer.exe also be registered?
Some options:
Add a new web-application that users can login-to using a web-browser and register their RandomNumberConsumer.exe installation (which adds a new Client registration in identity.example.com's Client database, complete with a client secret) then the user manually copies and pastes the client secret into RandomNumberConsumer.exe's configuration file. The internal database maps each client registration with the tenant_id. This has the advantage of allowing individual client access revocation, but requires the user to perform manual configuration steps which are undesirable.
Have a single Client registration for RandomNumberConsumer.exe without any Client Secret, but the Client application needs a GUI component with which it can authenticate the user and it stores the user's associated access_token and refresh_token in its local configuration. This has the advantage of having a much simpler user-experience (as the user would open a RandomNumberConsumerConfiguration.exe program which then opens the web-browser to access the authentication page and gets the data using a redirect_uri with a temporary localhost or custom URI scheme value) but it means the RandomNumberConsumer.exe instance is associated with an individual human user when we only want it to be associated with the tenant instead.
Are there any other approaches that could be used instead?
Every instance of a client should have it's own id. random-number-generator-service should have one id (even when it runs in a web farm).
RandomNumberConsumer.exe is installed on different machines outside the domain, so should have a unique id per installation.
A client has nothing to do with a user as the sub claim is missing. The only time the client includes the sub claim is when it acts on behalf (and with consent) of the user. This can be the case for random-number-generator-service, but not for RandomNumberConsumer.exe where there is no user interaction (as it is a Windows Service) and consent is not needed as it is given when the user requested the installation.
When you are talking about a Windows Service then it is inevitable to configure the service. You can however implement configuration steps in the installer. So instead of having to build UI or hacking a configuration file, you can take the following approach:
User requests an installation of the program. When approved a client is created and attached to the tenant (ClientClaims), based on the user.
The user starts the download of the installer and receives the id/secret (on screen, email).
User starts the installation and in one of the steps the user has to enter the id/secret. This is acceptable since it is quite common when installing software.
This has the advantages you want and takes minimal steps from the user.
If the service has more configuration options and you want to give the user a UI to maintain the options then add a configuration program to the installer. This is quite common for routers and printers. There is no need for the user to login as it runs local (localhost website). You can add a link for the browser as shortcut.
We have a Vaadin / Spring Boot application which should be accessible via a browser and without login from intranet only.
We would like to implement SSO with the Windows login (Active Directory).
The goal is high security with least configuration as the application is sold to customers.
I came up with the following scenario:
receive the IP address of the client accessing the Vaadin-Application.
Look up in the Active directory / Domain controller, which is in RW mode and see which user is online with this IP address in this very moment.
check the rights of this user managed by the Active Directory Groups.
make application available with logged in user for the client requesting it.
IP spoofing is not possible (as the connection is bidirectional, also users have no access to network devices.)
this login process is only done once to initiate the session.
Am I correct with these thoughts? Can you see any security issues? Is it really necessary to use certificates?
What would you recommend if so? Kerberos, CAS, x509, SAML?
I trying to implement OAuth 2 provider for web service and then built native application on top of it. Also I want give access to API for third-party developers.
I read OAuth 2 specification already and can't choose right flow. I want authenticate both CLI and GUI apps as well.
First of all we have two client types - public and confidential. Of course both GUI and CLI apps will be public. But what is difference between this two types? In this case for what I need client_secret if I can get access token without it just by changing client type?
I tried to look at some API implementations of popular services like GitHub. But they use HTTP Basic Auth. Not sure it is a good idea.
Is there any particular difference? Does one improve security over the other?
As to the difference between public and confidential clients, see http://tutorials.jenkov.com/oauth2/client-types.html which says:
A confidential client is an application that is capable of keeping a
client password confidential to the world. This client password is
assigned to the client app by the authorization server. This password
is used to identify the client to the authorization server, to avoid
fraud. An example of a confidential client could be a web app, where
no one but the administrator can get access to the server, and see the
client password.
A public client is an application that is not capable of keeping a
client password confidential. For instance, a mobile phone application
or a desktop application that has the client password embedded inside
it. Such an application could get cracked, and this could reveal the
password. The same is true for a JavaScript application running in the
users browser. The user could use a JavaScript debugger to look into
the application, and see the client password.
Confidential clients are more secure than public clients, but you may not always be able to use confidential clients because of constraints on the environment that they run in (c.q. native apps, in-browser clients).
#HansZ 's answer is a good starting point in that it clarifies the difference between a public and private client application: the ability to keep the client secret a secret.
But it doesn't answer the question: what OAuth2 profile should I use for which use cases? To answer this critical question, we need to dig a bit deeper into the issue.
For confidential applications, the client secret is supplied out of band (OOB), typically by configuration (e.g. in a properties file). For browser based and mobile applications, there really isn't any opportunity to perform any configuration and, thus, these are considered public applications.
So far, so good. But I disagree that this makes such apps unable accept or store refresh tokens. In fact, the redirect URI used by SPAs and mobile apps is typically localhost and, thus, 100% equivalent to receiving the tokens directly from the token server in response to a Resource Owner Password Credentials Grant (ROPC) .
Many writers point out, sometimes correctly, that OAuth2 doesn't actually do Authentication. In fact, as stated by the OAuth2 RFC 6749, both the ROPC and Client Credentias (CC) grants are required to perform authentication. See Section 4.3 and Section 4.4.
However, the statement is true for Authorization Code and Implicit grants. But how does authentication actually work for these domains?
Typically, the user enters her username and password into a browser form, which is posted to the authentication server, which sets a cookie for its domain. Sorry, but even in 2019, cookies are the state of the authentication art. Why? Because cookies are how browser applications maintain state. There's nothing wrong with them and browser cookie storage is reasonably secure (domain protected, JS apps can't get at "http only" cookies, secure requires TLS/SSL). Cookies allow login forms to be presented only on the 1st authorization request. After that, the current identity is re-used (until the session has expired).
Ok, then what is different between the above and ROPC? Not much. The difference is where the login form comes from. In an SPA, the app is known to be from the TLS/SSL authenticated server. So this is all-but identical to having the form rendered directly by the server. Either way, you trust the site via TLS/SSL. For a mobile app, the form is known to be from the app developer via the app signature (apps from Google Play, Apple Store, etc. are signed). So, again, there is a trust mechanism similar to TLS/SSL (no better, no worse, depends on the store, CA, trusted root distributions, etc.).
In both scenarios, a token is returned to prevent the application from having to resend the password with every request (which is why HTTP Basic authentication is bad).
In both scenarios, the authentication server MUST be hardened to the onslaught of attacks that any Internet facing login server is subjected. Authorization servers don't have this problem as much, because they delegate authentication. However, OAuth2 password and client_credentials profiles both serve as de facto authentication servers and, thus, really need to be tough.
Why would you prefer ROPC over an HTML form? Non-interactive cases, such as a CLI, are a common use case. Most CLIs can be considered confidential and, thus, should have both a client_id and client_secret. Note, if running on a shared OS instance, you should write your CLI to pull the client secret and password from a file or, at least, the standard input to avoid secrets and passwords from showing up in process listings!
Native apps and SPAs are another good use, imo, because these apps require tokens to pass to REST services. However, if these apps require cookies for authentication as well, then you probably want to use the Authorization Code or Implicit flows and delegate authentication to a regular web login server.
Likewise, if users are not authenticated in the same domain as the resource server, you really need to use Authorization Code or Implicit grant types. It is up to the authorization server how the user must authenticate.
If 2-factor authentication is in use, things get tricky. I haven't crossed this particular bridge yet myself. But I have seen cases, like Attlassian, that can use an API key to allow access to accounts that normally require a 2nd factor beyond the password.
Note, even when you host an HTML login page on the server, you need to take care that it is not wrapped either by an IFRAME in the browser or some Webview component in a native application (which may be able to set hooks to see the username and password you type in, which is how password managers work, btw). But that is another topic falling under "login server hardening", but the answers all involve clients respecting web security conventions and, thus, a certain level of trust in applications.
A couple final thoughts:
If a refresh token is securely delivered to the application, via any flow type, it can be safely stored in the browser/native local storage. Browsers and mobile devices protect this storage reasonably well. It is, of course, less secure than storing refresh tokens only in memory. So maybe not for banking applications ... But a great many apps have very long lived sessions (weeks) and this is how it's done.
Do not use client secrets for public apps. It will only give you a false sense of security. Client secrets are appropriate only when a secure OOB mechanism exists to deliver the secret and it is stored securely (e.g. locked down OS permissions).
is the SAML protocol (Sing Sign ON) used soley for web apps and web services, or is it also used for standard applications?
REVISED:
I am looking for some windows (Standard Applications (not web based)) protocols for Single Sign On
If you are looking at Windows specifically, why not use Kerberos and Integrated Windows Authentication? It's built into Active Directory and Domain Controllers. It doesn't really work once you start crossing into the Internet and different security domains but it works well behind your firewall in a corporate environment.
However, SAML can be used for desktop applications. I've run into applications before that would retrieve the Kerberos ticket from the Desktop, make a WSTrust/RST call to an STS to validate the Kerb token and get back a SAML token in the RSTR that would be embedded into a Web Services call that the desktop application needed to make.
SAML allows secure web domains to exchange user authentication and authorization data and by definition would require an internet connection to do so. So no you would not want to use it for a desktop application.
Revised
here are the links for active directory implementation with Delphi.
http://www.agnisoft.com/white_papers/active_directory.asp
http://adsi.mvps.org/adsi/Delphi/index.html
Is there any way to have a custom form for Windows authentication so that the device used when authentication doesn't need to support NTLM in order to work? Also, is there a way to keep the automatic login for intranet users so that they do not need to login if they are already on their computer?
Is there any way to have a custom form
for Windows authentication so that the
device used when authentication
doesn't need to support NTLM in order
to work?
I guess you want to be able to authenticate users coming from outside the intranet.
In that case, Windows Authentication is not the right choice since it uses Windows user's credentials for the authentication and therefore more applicable for intranet applications.
If you really want to have Windows Authentication, your client requires NTLM or Kerberos authentication support.
Also, is there a way to keep the
automatic login for intranet users so
that they do not need to login if they
are already on their computer?
For this you can use Windows Authentication.