Authentication that suits your needs
Authentication is a core non-functional requirement of almost every enterprise application and has been pretty much the same for a long time. But 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 login 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, login automatically without the need to enter their credentials.
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.
SAML
- Idp — SAML web client
- Idp Mobile — SAML mobile client
OAuth2
- OAuthSample — OAuth2 web client
- oAuthMobile — OAuth2 mobile client
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 specific 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.
- GoogleOAuth — Google web client
- Google Login Plugin — Google mobile client
- Facebook Connector — Facebook web client
- Facebook Login Plugin — Facebook mobile client
- Twitter Connector — Twitter web client
- Twitter Plugin — Twitter mobile client
- Microsoft Login Connector — Azure Active Directory web client
- Azure AD Mobile Plugin — Azure Active Directory mobile client
Custom built authentication
If none of the above methods answers 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 users 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.
- IdP Server — SAML identity provider
- oAuth2Provicer — OAuth2 identity provider
In an OutSystems factory, you can have a mix of this 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 their 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.
