In
this post, I will describe the new authentication schemes supported in GAM.

GAM stands for GeneXus Access Manager. It is a built in functionality of GeneXus to implement authentication and authorization in your applications.

To introduce the tools, first we will take a look at what is going on in the world of security and authentication.

The Auth0 survey about authentication schemes available on the market reveals that:

• 28% are offering multi-factor authentication, which is the same as Two-Factor Authentication. This means that the user has to validate two factors to enter the application. In general, the first factor is the password and the second factor is a random number or something sent via email or SMS.
• 45% are offering single sign-on through existing services. This is very good for end users, because companies allow them to have a single username and password to access all their applications or products.
• 21% are offering biometric authentication, mainly in native applications on mobile devices.
• 31% are offering authentication through social networks. The most used ones are Google, Facebook, and Twitter.
• Lastly, 20% are allowing users to enter without a password. With this method, the user doesn’t need to have a password to enter the application. Instead, they simply enter an email address and the system emails them the access code to that application. This code is only valid for a very short period of time.

What does GeneXus offer regarding all these authentication schemes? 

Let’s see what GeneXus offers to configure each of these authentication schemes:

• OAuth 2.0, 
• OpenID Connect, 
• One-Time Password, and
• Two-Factor Authentication. 

OAuth 2.0 Protocol 

OAuth 2.0 is the most widely used protocol among identity providers such as Google, Facebook, Microsoft, etc.

How does the OAuth 2.0 protocol work? Let’s use a specific example: an end user is going to browse an application and we have 3 applications on the Internet (see image below). These applications are 3 independent knowledge bases with their own database, and each one has GAM enabled. 

The applications on both ends are the Clients, and the application in the middle is the Identity Provider. I have named the clients “GeneXus.com” and “Download Center;” the Identity Provider could be the “GeneXus Account.”

When the user accesses this application, it knows that an Identity Provider performs the authentication, so the application redirects to this Identity Provider, which displays a Login screen.

This is one of the strong points, as credentials are only entered in the Identity Provider. They are not entered in the clients. The Identity Provider is responsible for validating these credentials and if they validate correctly, it responds to the client, which displays the authenticated user screen. 

The OAuth protocol is a bit more complex than this; here, between the Identity Provider and the Client there is more information exchange. What the Identity Provider responds to the Client is called an access_code. With that code, the client requests the token and after obtaining the token, it requests information about the user of that token.
Once it has all that information in its local database, the user is created or updated, a session and a local token are created, and the authentication ends there. Behind it all is the OAuth 2.0 standard.

What happens if, while browsing this application, I access another application that also authenticates with the same Identity Provider?

The Identity Provider will detect that it is already authenticated, and will directly respond with the access_code to this application. Here, the user is also created or updated and then redirected to the screen with the authenticated user. Note that this not only centralizes the authentication, but also provides single sign-on between all the company’s applications.

How much work does it take to configure this in our applications?

The good news is that with GeneXus, you don’t have to program anything but only make configurations. 

In this video, I give step-by-step instructions to configure security with GAM.

OpenID Connect

OpenID Connect is becoming the most widely used protocol among all identity providers. This is because OpenID Connect runs inside OAuth 2.0. We can say it makes it more standardized, because the OAuth 2.0 standard does not include how to obtain the user’s information.

So, what you configured in this User Information tab is no longer necessary when using OpenID Connect. You can leave that URL blank. What happened before was that each Identity Provider returned the User Information that the Identity Provider wanted.

Now there is a standard and you can configure it in the Authorization sector. When you enter there, you will have an option to enable this OpenID Connect protocol. Simply by enabling it, GAM begins to store a new property that returns the Identity Provider called ID Token. The GAM stores it and makes it available to be used. If you need to make a request to that Identity Provider, you can use it. However, to enable 100% of the protocol you would have to enable validation, where it says Validate ID Token.

The ID Token is a JSON web token that is signed by the provider. For this reason, here you have to confirm who the provider of the ID Token is. Also, you need to have on your local server, in a local path of the server, a public certificate of that provider. 
In this way, you obtain that JSON Web Token that, among other things, has the information of the authenticated user.

One-Time Password (OTP)

It is a new type of GAM authentication, just as you could configure authentication with Google or Facebook. 

Remember that a One-Time Password is a password that is given to you and can only be used once for a short period of time. You can choose its length, if the generated key is only made up of numbers, or if you want it to be alphanumeric.

The lifetime of the auto-generated code and many other security properties can be selected.

If you are interested in this authentication method, I suggest reading One-Time Password (OTP) and Two-Factor Authentication (2FA)

Two-Factor Authentication

It is also known as Multi-Factor Authentication; in both cases, two factors will always be validated.

Usually a password is validated first. We have them available in all types of authentication that do not do a redirect to authenticate, such as Local, Custom, External Webservice, and GAMRemoteRest.

There you will see these new properties where you can enable this functionality. Then you will choose the second type of authentication that you are going to use. They will be the One-Time Password Authentication Types that you have defined in this same GAM. You define how you want this second type of authentication to be generated, and the time the user will have to validate the two authentication factors. In this case, if users exceed 900 seconds to validate the two factors, they have to validate the first factor again.

Another interesting property is that you can select whether to force all the users of your application to do Two-Factor Authentication. If you don’t select it, each user can select whether they want to use this authentication method or not.

Don’t miss the video 2FA, one-time password, OpenID: All about the new authentication schemes
In it, I elaborate on all these concepts and give technical tips so that you can develop your applications integrated with each other and with all the existing authentication schemes. All this is possible with GeneXus 17!