Accueil > OpenID Connect OAuth Server by DnC > Discover

In a few words for users : After a single authentication procedure, you will be automatically connected to the applications. Theese applications will not be able to access your personal identifiers (login and password). With OAuth by DnC, your password can not be intercepted when you enter it, does not circulate on the Internet, is not registered anywhere !

In a nutshell for developers : An OAuth 2.0 + OpenID Connect server allows end-user authentication to be delegated to an independent system so that they can safely navigate your applications ; you will place great trust in the real identity of the users ; you will also be able to authenticate access to distributed resources (for example in the Cloud) in what can be likened to a virtual session, identified by the ID Token .

Why an authentication server ?

  (publié initialement le mercredi 24 avril 2019) par DnC

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 a G..gle or F ... account etc. account. 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.

Two-Factor Authentication (2FA)

  publié le par DnC

New EU regulation will require a two-factors authentication for payment, the ’Strong Customer Authentication’ (SCA) which will come into force in September 2019.

The need for 2-steps validation is also felt for connecting users to sensitive applications. The principle of two-steps validation (Two Factors Authentication, 2FA) is well known for several years and implemented in different ways, the most common being the code sent by SMS.

OAuthSD Implements two-factors Authentication by SMS or with Google Authenticator.

What is 2FA ?

Two Factor Authentication, also known as 2FA, two step verification or TFA (as an acronym), is an extra layer of security that is known as “multi factor authentication” that requires not only a password and username but also something that only, and only, that user has on them, i.e. a piece of information only they should know or have immediately to hand — such as a physical token.

After login, give a second proof

The process begins as usual, the end-user giving his login and password :

She/he is asked to provide a second proof of identity : OAuthSD offers the classic method by SMS or identification with Google Authenticator.

2FA by SMS

If this first step ends successfully, OAuthSD continues on a request for code by SMS :

The SMS is sent to the smartphone number registered with the user’s profile [1].

After confirmation, consent is requested if necessary, as usual :

2FA with Google Authenticator

Google Authenticator is a 2FA system that generates a TOTP.

What is TOTP ?

TOTP is a short form for Time-based One-time Password (usually called Token) which is password that can only be used once and is only valid to be used in a defined time range. Usually TOTP generators generate new passwords every defined tens of seconds.

This necessitates to register OAuthSD as a Google Authenticator application [2]. This is what the QRCode is used for. See many how-to on the Web. This is a one-time action for the smartphone life time : once it is done, GA will display a code every 30s : nothing to remember !

After confirmation, Consent is asked if necessary, as usual.

Why Google Authenticator ?

Google Authenticator has been provided by Google for several years and proved a user-friendly process. Many people have Google Authenticator (for free) on their smartphone, and would probably have difficulties adopting an other application.

What about tracking ? Applications delegate user identification to OAuthSD, this means Google see the OAuthSD server, not the applications. Google knows that a user is related to OAuthSD, but doesn’t see the relation with the application ... provided there is no tracking leakage elsewhere in this application !

And then ?

Other ID providers will follow soon, including our own (= your private) for a top level security.
We may develop any private system suited for the particular needs of our customers.

Il existe des informations complémentaires, connectez vous pour les voir.

Notes

[1The SMS identification method will fail if no number has been registered for the user trying to login.

[2Note that OAuthSD is registered on Google Authenticator, not client applications. The advantage of delegation of authentication is therefore retained to prohibit the tracking of end-user navigation.

OpenID Connect : Summary of all authorization flows

  publié le par DnC

The tables in this article summarize the flows offered by OpenID Connect and the underlying layer OAuth 2.0. It allows you to navigate to the corresponding chapters in the documentation.

Most of the features of OAuth 2.0 are integrated into the OpenID Connect protocol. Features of OAuth 2.0 and OpenID Connect can therefore be reached by OpenID Connect Endpoints [1].

Flow type according to the parameters of the call

1. Requests addressed to authorize endpoint. The different values of parameter_type (required) and scope openid (optional) determine the following Grant Type flows :

Grant Type response_type openid Obs.
OAuth 2.0 Authorization Code code N RFC 6749
OIDC Authorization Code code Y
OIDC Implicit id_token, id_token token Y OpenID Connect Implicit Client. "nonce" required
OAuth 2.0 implicit token X [2]  [3]
Hybrid code id_token Y "c_hash" required
Hybrid code token X Invalid [4]
Hybrid code id_token token Y Invalid [4]

Références :
- The OAuth 2.0 Authorization Framework.
- OpenID Connect Core 1.0 incorporating errata set 1 : Authentication using the Hybrid Flow.

Notes :
- About the response type "id_token" and "id_token token" :
these response types correspond to implicit flows that directly return the tokens. The "nonce" parameter must be present in the request.

- About response type "token code" and "token-id token code" :
these response types correspond to hybrid flows that directly return the token(s). OAuthSD is based on the OAuth 2.0 Server PHP library developed by Brent Shaffer. As part of OpenID Connect, it accepts only the hybrid flow request with the "code id_token" response type.


2. Queries sent directly to the token endpoint. These flows are only defined by OAuth 2.0 and do not return an identity token, whether or not the openid scope is specified.

Grant Type grant_type Access Token Refresh Token Rem.
Client Credentials client_credentials Y N  [5]
User Credentials [6] password Y N
JWT Bearer - Y N  [7]

References :
- RFC 6749 Client Credentials Grant,
- Specification draft-ietf-oauth-jwt-bearer-07 section 1


Summary of the features offered by the different OpenID Connect flows

See : https://openid.net/specs/openid-connect-core-1_0.html#Authentication

Property Authorization Code Flow Implicit Flow Hybrid Flow
All tokens returned from Authorization Endpoint no yes no
All tokens returned from Token Endpoint yes no no
Tokens not revealed to User Agent yes no no
Client can be authenticated yes no yes
Refresh Token possible yes no yes
Communication in one round trip no yes no
Most communication server-to-server yes no varies

Choose the flow based on the configuration

Not all flows have the same value for the protection of confidential data.
Before choosing an OpenID Connect feed, it is important to identify the configuration of the parties (applications, OIDC server, resource servers, etc.).

This problem is explained here : Typologie des applications au regard de la sécurité des données.

Notes

[1Although OAuth 2.0 endpoints can be addressed specifically to the OAuthSD server at URLs https: //oa.dnc.global/oauth / ...

[2Whether the openid scope is provided or not, this Implicit stream does not return an Identity token.

[3Unidentified flow of type Implicit to which the server responds.

[4Not yet implemented in the current state of development of the libraryOAuth 2.0 Server PHP.

[5Does NOT include a refresh token, see : http://tools.ietf.org/html/rfc6749#section-4.4.3

[6Or "Resource Owner Password Credentials Grant Type". We quote this stream, and OAuthSD implements it, only for the sake of completeness. This stream should not be considered as an authentication ; on the contrary, the use of this flow leads to an impersonation (on this subject, see : https://www.scottbrady91.com/OAuth/..., we therefore recommend not to use it.

[7This is very similar to the token exchange described here : Un jeton d’identification peut être utilisé pour ... and by this proposal of standard : Draft IETF : Token Exchange.

Legals

  publié le par DnC

Warning

Warning : This site is a demonstrator and a development tool, it may be unavailable and the saved data deleted at any time.

This application is a prototype in development. It is intended to enable DnC, its customers, and developers to test OAuth in their client applications and protected resource servers. Any use is at the risk of the user.

The documentation is also in constant becoming and can not replace the documents to which it refers.

The user should be aware of the differences that may exist between the OAuthSD server and OpenID Connect specifications : all features are not necessarily implemented by OAuthSD or are not yet so, some specifications are still drafts, some features are deemed less helpful or poorly secured. In addition, OAuthSD offers some interesting extensions that, without going against the standard, are not part of it. Finally, OAuthSD is intended to be implemented in the closed framework that constitutes a set of applications in a corporate realm which allows a certain freedom from the specifications.

DnC makes no warranties and disclaims any liability for any damage resulting from the application or documentation.

Rights

This entire site is covered by French and international legislation on copyright and intellectual property. All rights of reproduction are reserved, including for downloadable documents, code and iconographic and photographic representations.

The publisher claims the copyrights on all the texts of this site, except the translations which try to stick as close as possible to the original text indicated by reference. On the other hand, the publisher claims the rights related to the translation.

Code Release Policy

The goal of DnC is twofold :
- 1. Protect the code specifically created by DnC and the OAuthSD server configuration to make it more difficult for criminals or malicious hacker. For this, the code in the directories /commons, /oauth and /oidc is not open source but subject to a particular license.
- 2. Disseminate as much information and source code as possible to allow anyone to integrate authentication delegation and resource protection into their applications with the OAuthSD server. For that all the rest of the code, not present in the directories mentioned above, is diffused under license GPLv3 or another license indicated in the code, in particular that coming from other developers.

This policy applies both to the code present on the server underlying this website and to the code deployed among OAuthSD users.

Publisher information

- Publisher of the site : DnC SARL Degoy net Consultants - 76, avenue du General Leclerc - 92340 - Bourg la Reine - tel : 07 86 82 24 90

- Hosting private server rented to OVH SAS, 2 rue Kellermann - 59100 Roubaix - France implemented by DnC SARL.

- Editor : The editor of the site.

GDPR

In the current state of development, this site does not record any personal data permanently (the data entered by the authors and users are erased regularly and are supposedly fictitious) and does not require a declaration to the CNIL. We do not perform any processing on this data other than backups and do not broadcast them.

Cookie : We want to implement limited lifetime cookies on your computer. This cookies do not allow us to identify you ; it does not record any personal information or relative to the navigation of your computer on our site, but simply a random code to manage the continuity of navigation in the site (session). Note that this type of cookie does not require your prior consent because it is not a "tracking cookie". We inform you that it is up to you to oppose the registration of cookies by configuring your browser. However, this will cause malfunctions.