Posts

,

OAuth 2.0 – authorizing user access

OAuth 2.0 is an authorization protocol that allows a user to authorize access to data and APIs (resources) from one application to another. Even though OAuth 2.0 is not an authentication protocol, often times the user must be authenticated by the application providing access before access to resources can be authorized. In a nutshell, using the OAuth 2.0, protocol, a website that a user is trying to log into (also known as a service provider), can request authorization of the user to an identity provider (i.e. the SSO server). The identity provider can authenticate the user as it wants and can even prompt the user to authorize the access to the service provider. The service provider then receives an access token which can be used to call APIs or access the user’s data or identity information so the user can be logged into the website and can perform the operations required in the website.

You can read a more in-depth explanation of OAuth 2.0 in this Medium article. OmniDefend fully implements the OAuth 2.0 protocol and you can use OmniDefend to perform SSO to applications that support the protocol. In addition, if you are developing your own application, you can use the OAuth 2.0 protocol to allow users to use OmniDefend authentication to log into your website in a secure way.

Also Read: How To Choose The Right Password Manager For Your Needs

/by
,

SAML 2.0 – a popular B2B SSO protocol

In the past, single sign-on (SSO) was typically achieved only through “password fill”, where the SSO software would prompt the user the first time he or she visits a website to enter their password. Then the next time the user visits the site, the SSO software detects that there is a password saved and either automatically fills in the user’s password or prompts the user to authenticate before filling in the password. Softex’s OmniPass software and password save feature in Chrome, Edge and Firefox, are just some example of these SSO password managers. SAML was born from the idea that instead of saving a user’s username and password, a website that needed to login a user (“Service Provider”) could talk securely with the SSO software (“Identity Provider”), so the SSO software could authenticate the user’s identity and securely send back information about the user that authenticated so that the website could just login that user without any password. As long as the website were to “trust” the SSO software, this could be achieved.

Read more

/by

OpenId Connect – Yes, you have used it!

We have all used a website that allows you to “Sign-in with Google” or “Sign-in with Facebook” instead of creating yet another username and password for that you have to remember. But have you ever wondered how this is implemented? Well this is where OpenId Connect comes to the rescue.

OpenId Connect was developed to allow website developers to enable single-sign on from a variety of different “identity providers” using a common API. Let’s say you are a developer creating a new website called acmeproducts.com. Now, instead of asking the user to create an account where he has to provide a specific username and password along with his name, address, and other personal information, you can now use OpenId Connect to request that information from the user’s favorite identity provider (e.g. Google or Facebook) where the user has already provided that information.

When the user clicks the “Sign-in with Google or Facebook” button, he will be redirected to the appropriate service to login. Once logged in, your site, acmeproducts.com will get a token that will contain information about the user and you to get additional information about the user from the identity provider. The advantage here is that the user has one less username and password to remember, he just uses his Google or Facebook password and his account on acmeproducts.com is created automatically and he can login with the same Google or Facebook credential. In a nutshell, acmeproducts.com would be using Google or Facebook to achieve single sign-on for your user.

OmniDefend also supports OpenId Connect and can be configured for single sign-on to any website that supports selectable OpenId Connect identity providers. However, instead of using a username and password, the user can now use biometric, smart card, OTP, PIN or phone push notification based authentication to make the login and authentication process simpler and more secure. To configure OmniDefend for single sign-on using OpenId Connect, you will need to do the following:

  • Find out if the application allows single sign-on using 3rd party identity providers that are OpenId Connect compatible
  • Add an OpenId Connect application in OmniDefend and provide information about the application URLs for login and logout
  • Configure the application to redirect users to OmniDefend for OpenId Connect authentication. This will involve providing a ClientId and ClientSecret generated from the previous step and also providing the application with the URL where you are running OmniDefend

The end result will be a dialog like you see below, where your users authenticate with OmniDefend (biometric, smart card, OTP, etc) and then get automatically signed into the application using strong and secure authentication.

Login to your application using OmniDefend

Here is a great Medium article where you can read more about the OpenId Connect standard.

Also Read: 10 Tips on How to Protect Your Privacy & Files with OmniDefend’s Windows Desktop Security Features

/by