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).
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, from the resource point of view, 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 OP for "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?
OpenID Connect protects login credentials
OpenID Connect effectively protects user credentials (access identifiers like login, password, etc.). This is a huge security benefit by ensuring that this data will never be compromised and misused to access protected data.
In effect, the applications delegate the process to the authentication server (OP). In this phase, exchanges occur directly between the browser [1] and the OP. This results in the following benefits:
User credentials are secured on the authentication server.
In the connection phase (sign on), the user’s information remains unknown to the application to which he connects, and in particular to tracking operators; thus, a malware replacing the legitimate application cannot intercept the identifiers.
Browsing in an application based on several components distributed over the Internet and the exchange of data between these components are secured by a single authorization process.
OpenID Connect protects sensitive user data
When requesting connection to a client application, OpenID Connect provides the user with information about the author of the application and the personal data that the application wishes to access. Thus, the user accesses the application (or not) with full knowledge of the facts. OpenID Connect therefore reverses the connection paradigm: instead of asking the Internet user (the end user) for a login and password without any justification or guarantee on the processing that will follow, OpenID Connect presents a request for authorization justified by relevant information on the application and on what will happen to the personal data of the Internet user.
OpenID Connect protects sensitive data assets
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 the access authorizations are linked by a cryptographic signature which can be validated by the destination resource server.
As discussed earlier, OpenID Connect allows reversing the paradigm: allowing sensitive data resources to provide (or not) provide data based on the identity of the requesting application and user.
Disclaimer: It is important to note that OpenID Connect, like any other authentication system, does not ensure the security of applications or data services, but provides them with more complete and reliable information about the end user than simpler methods. On the one hand, security will depend on what applications and services do with this information, on the other hand, their intrinsic security as well as that of the network.
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!
Don’t trust the public network!
Finally, when it comes to the security of an entity’s applications and / or data accessed from the public space, no trust should be placed in the network: solutions such as VPN and proxy, acting at the level of the network layer, open wide the doors to the local network and should therefore be used with care. OpenID Connect acts at the level of the application layer and thus contributes to the ZTNA approach: it is not a question of authorizing access to the network, but to an application, and further more, with a user-dependent authorization scope. We can bet that with teleworking, many companies opened their network in haste will experience serious security accidents!
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, SSO, 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.
We offer a good example of the implementation of OIDC principles: the application DnC SaaS, a software as a service delivery system (SaaS). In this application, OAuthSD provides OIDC authentication and securely transmits parameters relating to subscribers’ subscriptions to SaaS applications.
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.
RSS 2.0