This has been changing in the last years mainly due to the massification of cloud services such as Google or Facebook that allow you to use a single login in multiple independent applications.

Nowadays you have multiple ways to log in a user in an application, and the good news is that OutSystems will support whichever mechanism you choose if it’s not built yet you can always extend the platform and build your own connector.

But before you start coding your own component take a look at the options that are already available and you will probably find one that will suit your needs.

Outsystems Internal Authentication

This is the most simple way of authenticating users into an OutSystems application. Using this method you don’t need any external system to manage your users, you can do it all using OutSystems built-in Users application.

Active Directory / LDAP

If you already manage your enterprise users in a central Active Directory you can use the built-in integration, just enable it in the Users application and you are ready to go. An interesting feature you can also enable if you have an Active Directory is the Integrated Authentication so that users that have their computers registered in the domain, log in automatically without the need to enter their credentials.

OutSystems Users Application
Users Application

External Identity Provider

There are several reasons why you would want to delegate your application authentication to an external provider. For instance, if you are building a B2C application you will probably want to allow your users to use their social networks logins such as Google or Facebook, this way it will improve the users experience and at the same time you can also gain access to some precious user information for your marketing team, if your users allow it, of course. But this can also be helpful in a B2E application, for instance, if you use Google’s G Suite internally, allowing your users to use the same login in your custom-built applications could also give them a better experience. Another good reason is to implement a single-sign-on approach across all of your systems taking advantage of cloud services such as Okta which can even provide you advanced features like One-Time Passwords.

But this is where things can get a bit more complex because of the multiple providers available, and also the different behaviors in web and mobile apps. The good news is that there are many connectors already available, we will cover some of the OutSystems Forge components we have come across with, that may be helpful for your specific use case.

Standard components

Most of the identity providers out there use known standards to implement their authentication mechanisms, and if you use a generic provider such as Okta, all you need to use is a generic SAML implementation in your applications, like the ones presented below.



Proprietary components

Even if an identity provider uses a known standard it may be useful to use a provider-specific component since it may implement something specifically for the provider, like parsing the information returned in a successful authentication.

Bellow, you can find a small set of the most common providers, if you can’t find the one you are looking for, take a look at the OutSystems Forge to see all the available components.

OutSystems Forge example
OutSystems Forge

Custom built authentication

If none of the above methods answer your needs, you can build your own authentication mechanism. This can be interesting in a scenario where you have a legacy system that you want to extend with OutSystems. If this legacy system has an internal user database you can connect to it using OutSystems and implement a connector so that the newly built OutSystems applications can be accessed with the exact same credentials as the legacy system.

OutSystems as an Identity Provider

Until now, we have only explored how you can authenticate your users in OutSystems applications, but in this topic, we will show you that you can use OutSystems as an identity provider for other applications.

This can be useful if you want to take advantage of your OutSystems internal authentication, your internal Active Directory or even your custom-built authentication to power other applications, from products to other custom-built software. To achieve this you can use the same standards described above, SAML and OAuth2. All you need to do is follow the instructions of the components below.

In an OutSystems factory, you can have a mix of these methods, you can have different authentication methods in different applications and you can even have different authentication methods in the same application. This can be helpful to manage internal and external users differently, for instance.

All of this is a good example that OutSystems delivers with its promise of being an open and extensible technology, even at core mechanisms of the platform such as authentication.

Disclaimer: Most of the components referenced in this article are developed and maintained by the community and should be validated before used in a production environment. This is important since they will be used to provide authentication to your applications which is a critical feature in terms of security.

Update: OutSystems launched at NextStep 2019 a built-in support for more authentication providers, make sure you look at the official documentation here.

Click here to read the next article from the author: It works on my device.