Discover

A single-page application is a "no back-end" application

There are several architectures for creating single-page applications. The trend is the "light server" architecture, which installs on the user agent (usually the user’s browser) the initial page containing Javascript code. This code will provide logic and state transitions for the application as it gets its RESTful API data protected by OAuth 2.0. In this configuration, the application resides on the user agent and not on the server : a single-page application is therefore a "no back-end" application.

SPAs can (now ?) implement Authorization Code Grant

There are many configurations in which the application hosts and the service endpoints are located on different servers : authentication server, protected resources (RS) or APIs.

Single-page apps are a good example.

In normal web usage, this multi-host or, more accurately, "multi-origin" approach is restricted for good security reasons. Declarations of cross-origin resource sharing ( Cross-Origin Resource Sharing, CORS ) make it possible to circumvent the constraint.

Browsers have improved since the design of the implicit flow. The CORS implementation to allow token request from JavaScript is now available, along with the necessary cryptography APIs to validate the JWT token signature.
It is therefore technically possible to use the authorization code flow for the authentication and authorization of applications without a back-end, including for single-page applications.

Does this mean that the use of this flow, in this configuration, guarantees data security ?

With SPAs, authentication security issues remain

SPAs are "no-back-end" applications. Their code is on the user agent, so anywhere, unlike applications "with back-end" whose unique code is protected within a server. As such :

 Are exposed in the code, in a more or less accessible way to the public :
- the identifier and the secret of the application,
- access or identity tokens.

With the identifier and the secret, a malicious application can obtain tokens. With the tokens, it could request data on behalf of the real application.

 The redirection URL is that of the application, therefore that of its host, ie the user-agent. It cannot be registered on the server and must be provided by the application.
If we are in the case of workstation user-agents ( desktops ) located in a trusted space (one or more known domains), it is still possible to compare this URL to a model saved on the server authorization. But even in this case, if the malicious application is on the same host [1], the distinction is impossible. If we are dealing with a mobile application, it becomes really risky.

 In the case of a mobile application, the token request at the Token entry point and the response do not circulate in a connection from server ( that of the application ) to server ( the authentication server ) in which both ends are identified, but between different unidentified mobiles and the authentication server. Thus disappears one of the recognized qualities of the authorization code flow applied to customers with back-end.

 There are many additional methods allowing the tokens to be linked to the user-agent or to the TLS connection identifier (TLS Token Binding). This makes it possible to prove that the user-agent (eg the end-user’s browser) is the one with which the authentication was performed and the token created. But this does not make it possible to discriminate between the good application and malware running on the same TLS link. In the same vein, the proof of possession technique Proof of Possession (PoP) seems to lead to the same conclusion.

In particular, the "Proof Key for Code Exchange, PKCE" method, applied to applications without a back-end as part of the Authorization Code flow, strengthens security by preventing authorization code hijacking. With this technique, the secret of the application is not used, which makes it possible not to disclose it. However, this prohibits identifying the application. PKCE makes it possible to ensure that the application which presents the authorization code is indeed the one in which the end user identification procedure was carried out, whatever this application may be.

In the case of a SPA as in that of any application without a back-end [2], it is not possible to ensure that the application presenting the token is indeed the expected application, and not malware.

Encapsulate encrypted data in a Javascript class ???

With SPAs, it is not possible to store credentials using traditional methods, such as access tokens in cookies and session storage. Instead, we imagine keeping sensitive data in JavaScript variables.

Some then recommend using a JavaScript class to store and provide these variables. This method receives the pretty name of "encapsulation" which gives a serious and innovative aspect to a method that is however very banal.

However, this is only an obfuscation method whose effectiveness is insufficient against a determined attacker. A simple web debugger (all modern browsers include one) allows you to execute the code step by step and see the variables pass.

Why do the specs confirm questionable practice ?

We can read in the document Health Relationship Trust Profile for OAuth 2.0 [3]

2.1.3. In-browser client with user delegation

This client type applies to clients that act on behalf of a particular resource owner and require delegation of that user’s rights to access the protected resource. Additionally, these clients are integrated with a web browser and effectively share an active session between systems.

These clients use the implicit flow of OAuth 2 by sending a resource owner to the Authorize endpoint for authorization. The user MUST authenticate to the Authorize endpoint. The user’s web browser is then redirected to a URI hosted by the client, from which the client can directly obtain an access token. Since the client itself never authenticates to the server and the token is made directly available to the browser, this flow is only suitable for clients embedded in a web browser, such as a JavaScript client without a backend server component. Whenever possible, preferred to use authorization code flow due to its superior security properties.

This type of client MUST NOT request or receive a refresh token. Access tokens issued to this type of client MUST be short-lived and SHOULD be discarded when the user’s authenticated session with the client expires.

It is therefore well recognized that there is a problem that the authorization code flow will not solve. This flow is arguably "higher security", but in the case of applications without a back-end it fails to authenticate the application, which may be overridden by malware located on the user agent.

Still, the wording of the paragraph suggests that the authorization code flow will do better than the implicit flow. And we avoid the exposure of the application’s secret in a simple way, and for good reason : "the client itself never authenticates with the server".

In this context, talking about the security offered by the "Authorization Code" flow is a masquerade : n.f. hypocritical comedy, deceptive staging.

An article presenting the cons and concluding on the pros

Here is an interesting article for the analysis that is made : SECURELY USING THE OIDC AUTHORIZATION CODE FLOW AND A PUBLIC CLIENT WITH SINGLE PAGE APPLICATIONS.

The author advocates the use of authorization flow with code for public SPAs, but provides a detailed analysis that highlights the multiple shortcomings of the configuration. Contrary to the title "Securely..." and the conclusion of the article, here is another ambiguity.

By titling on public apps, the author avoids at least disclosing the app’s secrecy, since there is none. This will facilitate the work of malicious applications ! we’re not going to ask for protected data like that.

Incompetence or marketing lie ?

Our article was motivated by reading this one : https://www.ubisecure.com/single-si....

The red thread of this article is simple :

1. Advances in browsers (CORS and cryptography) allow JavaScript to implement the authorization code flow.

2. So we no longer need to implement the implicit flow with the SPAs, but the Authorization Code flow.
Understood : since you know that the Authorization Code flow is the one to use with OIDC, and that you were told that the implicit flow was of questionable security, you understand that everything is fine now.

3. Of course, we have to store the tokens. You have to encapsulate them in a class, so they will be well hidden.

So, incompetence or intox ? Wouldn’t it be a question of making people believe in a new system and thus crediting the existence of a comparative advantage over the competition ?

Why distort the truth ?

OpenID Connect has a good image, it sells well. Too bad if the data is only secure in the case of classic web applications (with back-end). Want to keep up with the mobile app trend ? Then marketers will sell you OIDC without telling you about the limitations.
Better still : they will highlight complementary methods, such as PKCE or POP, suggesting that they provide the solution to the problem of authentication of a client application without a back-end.

What about headless servers ?

The "headless server" configuration is an architecture that allows writers to produce and organize content, while providing developers with structured data that can be displayed using a separate system on the frontend of a site. web or app.

We often end up, on the front-end, in an SPA.
But, since the data is served by an application with back-end, there is a way to ask the end user for OIDC authentication on this application, registered as a client of the OIDC server. If this gives a guarantee on the authorization of the user to access the data, it will not make it possible to identify the SPA and what it does with the data.

So there is no hope of securing SPAs ?

There is an interesting track with applications installed on mobile in Progressive Web App (PWA) mode. Under certain conditions, the code and data of PWAs are maintained, on the mobile side, identical to their model on the server side. Such a SPA - Headless Server architecture (see SPIP CMS headless + Gatsby) could therefore be suitably secured with OIDC.

i-Tego accompanies you

i-Tego (heiress of DnC) provides advice and assistance. We help our customers to implement their own OAuthSD server. We support Dev/Ops by transferring our skills to them, which results in using OIDC only in secure configurations.
And we fully recognize the work of IT to protect access to the network, and thus create the "trusted space" required for the correct application of OpenID Connect.

i-Tego chat bot

i-Tego propose aux entreprises un chat bot dont la base documentaire inclut leurs données propres.
Le prototype est visible ici : https://chat.i-tego.com
Attention ! produit en évolution constante, peut être indisponible.

This is an example built on i-Tego’s documents :

Q : what are key points to consider when using authorization code flow with native/mobile application ?

R : When using the authorization code flow with native/mobile applications, there are several key points to consider :

Security : Native/mobile applications cannot securely store the client secret, which could be exposed through reverse-engineering. Therefore, additional security measures such as Proof Key for Code Exchange (PKCE) should be implemented to mitigate this risk.

Client Type : Native/mobile applications should be registered as "public" clients on the server, meaning they have a null secret.

Code Challenge : Instead of the client secret, the application should generate a random code verifier and send its hash as the code challenge parameter during the authorization request.

Token Exchange : After the user authentication and receiving the authorization code, the application exchanges it for tokens, including the code verifier parameter.

Code Challenge Creation : The code challenge is created by hashing the code verifier with SHA256 and encoding it in base64 URL format. The code challenge method should be set to ’S256’.

Additional Security Measures : Implementing methods like PKCE enhances the security of the token issuance process and helps prevent interception or misuse of authorization codes by malicious applications residing on the same user-agent.

These considerations help ensure the security and integrity of the authorization process for native/mobile applications using the authorization code flow.

Q : what says OAuthSD about this : is authorization flow as god for native/mobile application as for web application ?

R : OAuthSD emphasizes the importance of using the Authorization Code flow for web applications due to its ability to provide a secure way to handle authorization. This flow is particularly well-suited for web applications that require a constant connection to the server and deal with sensitive data. However, OAuthSD also mentions that certain systems may find the simplicity of OAuth 2.0 flows, such as the Client Credentials Grant, more suitable for their needs, especially in trusted environments where user identification is not a priority.

In summary, while the Authorization Code flow is highly recommended for web applications, OAuthSD acknowledges that different application types may have varying requirements and security considerations when it comes to authorization flows.

Sources :

Découvrir - OpenID Connect OAuth Server dédié.pdf (page 22)
Authentifier l’application - OpenID Connect OAuth Server dédié.pdf (page 1)

Q : what says OAuthSD about security of authaurization code flow for native/mobile applications ?

R : OAuthSD emphasizes the importance of security when using the Authorization Code Flow for native/mobile applications. The Authorization Code Flow is considered safe when applied to web applications with a back-end, as it provides a secure way to authenticate and authorize access to protected resources. However, for native/mobile applications, additional considerations are needed to ensure the security of the authentication process.

OAuthSD highlights the need to verify the origin of requests received by a resource server to prevent token theft by foreign applications. This strict security approach leads to the conclusion that the Authorization Code Flow is only considered safe for web applications with a back-end. This means that for native/mobile applications, there may be limitations or vulnerabilities that need to be addressed to ensure the security of the authentication process.

In summary, while the Authorization Code Flow is a secure option for web applications with a back-end, additional security measures may be necessary when implementing this flow for native/mobile applications to prevent unauthorized access and protect sensitive data.

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.

Position of the problem

Most SaaS systems integrate the application and the sales system in one software.

If several web applications are to be distributed in SaaS mode by the same entity, the first problem to be solved consists in providing single sign-on service (SSO) between the sales system and the different applications. No problem, that’s the role of an OIDC server, OAuthSD does this very well.

The second problem, more interesting, consists in transmitting information from the sales system to applications.
Regarding the validity of the subscription and the (paying) options, this data must be secured, ie allow the recipient application to control :
 integrity (the data have not been falsified),
 the authenticity of their origin (they were indeed delivered by the SaaS system),
 the actuality (these are indeed data valid at the time considered),
 the destination (these are data relating to this application),
 and of course the identity of the end user (it is not an intruder who uses the application).

The solution : OAuthSD

OAuthSD allows integrating SaaS data as additional declarations in JWT token payload. The recipient application (client of the OIDC server) will only need to validate the identity token by introspection (and not locally to ensure the token validity at this time) to carry out the checks described above in a single operation.

The system DnC SaaS and one of its applications NSS Lite perfectly illustrate this technical.

To achieve this we have :
 integrated in the same application the OIDC server and the sales system,
 developed OIDC-SaaS extension plugins, in particular for applications based on SPIP or Wordpress.

We would be happy to assist SMEs to allow them to develop their own SaaS system and adapt their web applications.
Our positioning of advice and assistance would allow our customers to developp their applications independently of expensive external providers. And third-party systems that are risky in terms of security : why feed big data to the benefit of your competitors ?

In the context of COVID-19, telework leads many employees to access their company network by means of a VPN tunnel from the personal computer or - absolute horror - the family computer. Checks should be made at this level.

Principles of ZTNA

It is about protecting the information system (IS) and sensitive data based on the principle that nothing and no one should be trusted. From user equipment to application, there are three general principles to apply :

1. Control of the materials used to access the IS : The sole control of the end user is not sufficient, it is also necessary to control the user agent by means of which she/he accesses the network and the applications, and his/her hardware also.

2. Multi-factor authentication : Authentication (at least two factors, or Two Factors Authentication, TFA) requires multiple proofs of identity from the end user.

3. Minimum privilege : Give users only access to the resources or data they need to perform their tasks.

How is OpenID Connect compared to this principles ?

1. OpenID Connect intervenes at the application level. OIDC cannot therefore replace the means of identifying and controlling the material layers. However, the Authorization Code Grant, when applied to "back-end" applications and services, provides a way to identify these components at the hardware level. On this subject, see : Verifying the origin of the request received by a resource server.

2. Multi-factor identification is not part of the OpenID Connect standard. The identification layer of the Authorize controller must implement several identification means, OAuthSD provides multi-factor identification.

3. By allowing identity tokens and privilege information to be conveyed by the identity token (ID Token) and guaranteeing its integrity by means of the token signature, OpenID Connect opens a means of controlling access to applications and data. OAuthSD allows the transmission of privileges.
However, it all depends on what the protected applications and resources will do with this information.

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.

In conclusion :

Applications of the ZTNA principles most often aim to replace access by VPN, and are therefore interested in the transport layer. Identification and control of hardware integrity is still the poor relation of security solutions, OIDC adds nothing.

OpenID Connect extends security at the application level (in the upper layer of the OSI model) and therefore finds its place in a complete ZTNA approach.

However, the difficulty of OIDC lies in the need to adapt applications and protected data resources by incorporating an OIDC module into them. See : Adaptation des applications.

Prospects for the evolution of OAuthSD

Note that the OAuthSD server already integrates some security functionalities at the level of the hardware and transport layers, and will bring more and more as it is developed, the OIDC server becoming part of OAuthSD.

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 the user owns, that is with them and that no one else owns or knows about.

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 : SMS or Google Authenticator. We add our own highly securised identification system : DnC’s IdentMaster.

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 !

TFA with DnC’s IdentMaster

We have developped DnC’s IdentMaster, a passwordless mobile application that can be used as first as well as second authentication method.

With the DnC’s IdentMaster application installed on your mobile, you just need to scan the QR-Code presented by the application to open your OpenID Connect session :

Configure 2FA on OAuthSD

A request for a second validation is presented to the end user :
 if the reserved scope "tfa" is present in the authorization request and if the application has been registered on the server with the scope ’tfa’.
 If the LOGIN_WITH_TFA configuration constant is set to true, the 2FA form will always be presented to the end user after the login form.
 the TFA_PROVIDER configuration constant is used to define the second mode of identification ("gangsta", "checkbysms ", " smartconnect "...).

And then ?

In the current state of development, OAuthSD offers three methods for 2FA : TFA by SMS (the classic solution !), Google Authenticator and SmatConnect.

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, as we did with the OpenID Connect Identification with ID Card : Aramis .

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 :

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.

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

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.

Warning

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.

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 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 : i-Tego
6, place de la Gare
08000 Charleville-Mézières - France.

SIRET : 901 205 583 00023 RCS Sedan

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

 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.