Accueil > OpenID Connect OAuth Server by DnC > Why an authentication server ?

Why an authentication server ?

Social networks have popularized authentication as a means for the user to allow access to his personal data. Others have only seen in OAuth the unique identification (Single Sign-On, SSO).

Without neglecting these objectives, the control of the user access to applications, and of the applications to the protected resources, constitute the angle of attack of this site.

Who needs an authentication server ?

OAuth Server by DnC is built on the OAuth 2.0 architecture. Here is an example application given on page 5 of the specification RFC 6749 :

For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo- sharing service (resource server), without sharing her username and password with the printing service. Instead, she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing service delegation specific credentials (access token).

OAuth allowing to authenticate outside the applications, this has two advantages :
- the user’s information remains unknown to the applications, and in particular to the tracking operators,
- navigation in an application composed of several components spread over the Internet and the exchange of data between these components are secured by a single authorization process.

In addition, when requesting a connection to a client application, OAuth provides the user with information about the author of the application and the personal data that the application wants to access. Thus, the user accesses the application (or not) with full knowledge of the facts. OAuth therefore reverses the paradigm of the connection : instead of asking the user (the end user) for a login and a password without any justification or guarantee on the treatments that will follow, OAuth presents a justified request for authorization by relevant information about the application and what will happen to the user’s personal data.

What is it exactly ?

Here is the summary given at the top of the OAuth 2.0 Specification (RFC 6749) :

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

Let’s analyze this text :

"framework " : Because OAuth 2.0 provides high-level abstraction capabilities, different protocols will incorporate it to meet a particular case. This is the case of OpenID Connect, which extends OAuth to provide an authentication protocol, allowing resource servers to act according to the identities of the end user and the application. This is also the case of OAuth Server by DnC (OAuthSD) which offers an access token verification protocol as well as an inter-application session service.

"third-party application" : this implies that OAuth defines three components : the client application that accesses a resource server through an authorization server, the latter being physically distinct from the other two components. Note that one should speak of "third-party applications" because OAuth is very effective in controlling access to a client’s data with different resource servers, so that OAuth is an indispensable tool to secure the data exchanges between distributed applications in the Cloud.

"limited access" : it is an allusion to the mechanism of scopes allowing to specify the extent of the accessible data and the authorized actions on these data.

"an HTTP service" : This specification is intended for use with HTTP (RFC2616). The use of OAuth on any protocol other than HTTP is out of the subject. This makes it a particularly easy system to implement as part of a web application using HTTP REST resources.

"ie by allowing the third-party application to gain access on its own behalf" : this demonstrates that OAuth is not limited to providing end-users with the means to control access to their personal data. OAuth has many applications for the control of exchanges between applications and data servers, which is very relevant in the case of applications and data distributed in the cloud.

This last observation is crucial to understand the full range of possible applications. Originally, OAuth and OpenID Connect were designed to protect the sensitive data belonging to the end user, who is asked permission to access it. The vocabulary used and the examples given in the specifications are strongly oriented by this vision.

However, with a little hindsight, we see that we are in the presence of a set of techniques that can also do the opposite : to ensure that the end user and the client application are the ones they claim to be.

Is OAuth 2.0 an authentication system ?

Authentication assumes that the protected application, which is granted permission to deliver the information to the client application, can identify the end user who initiated the authorization.
OAuth 2.0 provides an excellent foundation, but must be completed to provide authentication.

OpenID Connect

OpenID Connect is an authentication layer built on OAuth 2.0. The authorization server (or "OpenID provider" in this case) contains information about a person. OAuth is used to protect this information, allowing a third-party application (client) to access it on behalf of a person. To authorize the dissemination of information, the person is authenticated and the OpenID Provider provides the client application with details including the identity of the person and the time of authentication.

How does OAuth improve application security ?

In itself, OAuth effectively protects access credentials (login, password, etc.). This is a huge security benefit in ensuring that this data will never be compromised and diverted to access protected data.

Regarding access to protected resource servers (for example a web service), OpenID Connect provides an identity token in which the identity of the client application, that of the user and authorization of access are linked by a cryptographic signature that can be validated by the recipient resource server.

A lot of work remains to be done on the applications side :

OAuth 2.0 does not define how a protected resource server should check the validity of the access token or how to interpret the scope of permissions (scopes). Moreover, neither OAuth, nor OpenID Connect, nor finally OAuth Server by DnC defines how the authentication function on the resource server side should be implemented.

To convince yourself of the reality of the problem, read from Eran Hammer, one of OIDC experts :

"The reason this is out of scope for the specification is the wide range of ways to accomplish this connection between the two entities. The main question is how complex is your deployment."

There are security functions that are entirely the responsibility of the protected resource servers. An authorization server provides an access token and authentication information, the resulting security will ultimately depend on what the protected resource server is doing, or not doing !

Easily facilitate navigation and data exchange within a multiple application

OAuth has many applications, however the following cases illustrate the possibilities :

Single sign-on for an application group

When the application includes different software on different sites, or uses multiple servers (this is the case "in the Cloud"), or if it is based on a REST architecture (no state or session), it is not It is practicable to ask the same user several successive authentications. See how OAuthSD provides the solution without the need to modify applications : SLI, SLO et SRA sont dans un bateau : OAuthSD.

A very simple case scenario is that of a CMS (Wordpress, SPIP ...) to which one wishes to add an application of forum foreign to the CMS (SPIP, PhpBB, WordPress ...). The authentication server allows to ask only once the user to identify himself.

This is very powerful in the case of a sales application coupled to a CMS and linked with several blogs and forums : the navigation of a user through the group of applications will require only one procedure of authentication. It is also conceivable to authorize the access of this user to public pages relating to a CRM (or more generally to an ERP) linked to the sales site.

Security of communication between applications

A classic case scenario is that of a main application using various external resources. Once the user authenticates on the main application, the resource servers must be certain of the origin of the requests made to them.
At a minimum, the authentication server makes it possible not to reveal the login and password of the user to third-party applications. But the decisive advantage of OpenID Connect is to provide an identity token in which the identity of the client application, the user identification and access permissions are linked by a cryptographic signature that can be validated by the recipient resource server.

Cross applications session

In addition to the services defined by the OAuth stantard, OAUTH Server by DnC offers the exclusive means of exchanging information in a secure way between web applications : it is the purpose of CloudSession.

Web application providers, protect your interests and protect your customers

Being website owner or developer, you can solve the issue of single sign-on by delegating it to G..gle, F ... book etc.. By doing so, you give these providers a great opportunity to analyze your customers’ behavior and target their ads. Best of all : you require your customers to record confidential information on these services, most of which, beyond the username and password, are useless for the sole purpose of authentication !

Moreover, do you think that this way of doing things is compatible with the General Data Protection Regulation (GDPR) ?

Protect your business interests

You may think that in any case, most of your customers have an account by G..gle or F ... etc. That’s right. But all is not lost : you can at least ensure that these advertising providers do not track the navigation of your customers in your applications (tracking), which would not fail to cause the display advertisements for your competitors in the following browsing of your customers on the web.

Create trust

By using our authentication platform, you show your customers that you respect their privacy by protecting their personal data.